Broadcasting signal transmission apparatus, broadcasting signal reception apparatus, broadcasting signal transmission method, and broadcasting signal reception method

ABSTRACT

The present invention proposes a method for transmitting a broadcasting signal. The method for transmitting a broadcasting signal according to the present invention proposes a system which can support a next generation broadcasting service in an environment that supports next generation hybrid broadcasting using a terrestrial broadcasting network and an Internet network. Further, in the environment that supports the next generation hybrid broadcasting, the present invention proposes an efficient signaling scheme which can cover both the terrestrial broadcasting network and the Internet network.

TECHNICAL FIELD

The present invention relates to an apparatus for transmitting abroadcast signal, an apparatus for receiving a broadcast signal andmethods for transmitting and receiving a broadcast signal.

BACKGROUND ART

As analog broadcast signal transmission comes to an end, varioustechnologies for transmitting/receiving digital broadcast signals arebeing developed. A digital broadcast signal may include a larger amountof video/audio data than an analog broadcast signal and further includevarious types of additional data in addition to the video/audio data.

DISCLOSURE Technical Problem

That is, a digital broadcast system can provide HD (high definition)images, multichannel audio and various additional services. However,data transmission efficiency for transmission of large amounts of data,robustness of transmission/reception networks and network flexibility inconsideration of mobile reception equipment need to be improved fordigital broadcast.

Technical Solution

The present invention provides a system capable of effectivelysupporting future broadcast services in an environment supporting futurehybrid broadcasting using terrestrial broadcast networks and theInternet and related signaling methods.

Advantageous Effects

The present invention proposes a method for efficiently providing hybridbroadcast using both broadcast networks and the Internet.

The present invention proposes app-based enhancement on the basis ofapplications for basic broadcast services.

The present invention proposes a method for providing app-basedenhancement in synchronization with a broadcast service.

The present invention proposes architectures according to variousprotocols between a PD and a CD and a method for communication betweenthe PD and the CD and between applications according to architectures.

The present invention proposes architectures and signaling methods foreffectively delivering information such as an ESG and an EAS from a PDto a CD.

DESCRIPTION OF DRAWINGS

The accompanying drawings, which are included to provide a furtherunderstanding of the invention and are incorporated in and constitute apart of this application, illustrate embodiment(s) of the invention andtogether with the description serve to explain the principle of theinvention. In the drawings:

FIG. 1 illustrates a receiver protocol stack according to an embodimentof the present invention;

FIG. 2 illustrates a relation between an SLT and service layer signaling(SLS) according to an embodiment of the present invention;

FIG. 3 illustrates an SLT according to an embodiment of the presentinvention;

FIG. 4 illustrates SLS bootstrapping and a service discovery processaccording to an embodiment of the present invention;

FIG. 5 illustrates a USBD fragment for ROUTE/DASH according to anembodiment of the present invention;

FIG. 6 illustrates an S-TSID fragment for ROUTE/DASH according to anembodiment of the present invention;

FIG. 7 illustrates a USBD/USD fragment for MMT according to anembodiment of the present invention;

FIG. 8 illustrates a link layer protocol architecture according to anembodiment of the present invention;

FIG. 9 illustrates a structure of a base header of a link layer packetaccording to an embodiment of the present invention;

FIG. 10 illustrates a structure of an additional header of a link layerpacket according to an embodiment of the present invention;

FIG. 11 illustrates a structure of an additional header of a link layerpacket according to another embodiment of the present invention;

FIG. 12 illustrates a header structure of a link layer packet for anMPEG-2 TS packet and an encapsulation process thereof according to anembodiment of the present invention;

FIG. 13 illustrates an example of adaptation modes in IP headercompression according to an embodiment of the present invention(transmitting side);

FIG. 14 illustrates a link mapping table (LMT) and an RoHC-U descriptiontable according to an embodiment of the present invention;

FIG. 15 illustrates a structure of a link layer on a transmitter sideaccording to an embodiment of the present invention;

FIG. 16 illustrates a structure of a link layer on a receiver sideaccording to an embodiment of the present invention;

FIG. 17 illustrates a configuration of signaling transmission through alink layer according to an embodiment of the present invention(transmitting/receiving sides);

FIG. 18 is a block diagram illustrating a configuration of a broadcastsignal transmission apparatus for future broadcast services according toan embodiment of the present invention;

FIG. 19 is a block diagram illustrating a bit interleaved coding &modulation (BICM) block according to an embodiment of the presentinvention;

FIG. 20 is a block diagram illustrating a BICM block according toanother embodiment of the present invention;

FIG. 21 illustrates a bit interleaving process of physical layersignaling (PLS) according to an embodiment of the present invention;

FIG. 22 is a block diagram illustrating a configuration of a broadcastsignal reception apparatus for future broadcast services according to anembodiment of the present invention;

FIG. 23 illustrates a signaling hierarchy structure of a frame accordingto an embodiment of the present invention;

FIG. 24 is a table illustrating PLS1 data according to an embodiment ofthe present invention;

FIG. 25 is a table illustrating PLS2 data according to an embodiment ofthe present invention;

FIG. 26 is a table illustrating PLS2 data according to anotherembodiment of the present invention;

FIG. 27 illustrates a logical structure of a frame according to anembodiment of the present invention;

FIG. 28 illustrates PLS mapping according to an embodiment of thepresent invention;

FIG. 29 illustrates time interleaving according to an embodiment of thepresent invention;

FIG. 30 illustrates a basic operation of a twisted row-column blockinterleaver according to an embodiment of the present invention;

FIG. 31 illustrates an operation of a twisted row-column blockinterleaver according to another embodiment of the present invention;

FIG. 32 is a block diagram illustrating an interleaving addressgenerator including a main pseudo-random binary sequence (PRBS)generator and a sub-PRBS generator according to each FFT mode accordingto an embodiment of the present invention;

FIG. 33 illustrates a main PRBS used for all FFT modes according to anembodiment of the present invention;

FIG. 34 illustrates a sub-PRBS used for FFT modes and an interleavingaddress for frequency interleaving according to an embodiment of thepresent invention;

FIG. 35 illustrates a write operation of a time interleaver according toan embodiment of the present invention;

FIG. 36 is a table illustrating an interleaving type applied accordingto the number of PLPs;

FIG. 37 is a block diagram including a first example of a structure of ahybrid time interleaver;

FIG. 38 is a block diagram including a second example of the structureof the hybrid time interleaver;

FIG. 39 is a block diagram including a first example of a structure of ahybrid time deinterleaver;

FIG. 40 is a block diagram including a second example of the structureof the hybrid time deinterleaver;

FIG. 41 is a block diagram of an electronic device according to anembodiment of the present invention;

FIG. 42 is a diagram for description of connection of a first clientaccording to an embodiment of the present invention;

FIG. 43 is a diagram for description of connection of a second clientaccording to an embodiment of the present invention;

FIG. 44 is a diagram for description of connection between the first andsecond clients according to an embodiment of the present invention;

FIG. 45 is a diagram for description of an additional connection requestaccording to an embodiment of the present invention;

FIG. 46 is a diagram for description of connection between clients whenan IP address is not present according to an embodiment of the presentinvention;

FIG. 47 is a diagram for description of standby connection forconnection between applications according to an embodiment of thepresent invention;

FIG. 48 is a diagram for description of a new connection request forconnection with the second client according to an embodiment of thepresent invention;

FIG. 49 is a diagram for description of setting of the first client whenan IP address is included according to an embodiment of the presentinvention;

FIG. 50 is a diagram for description of setting of the first client andthe second client when IP addresses are included according to anembodiment of the present invention;

FIG. 51 is a diagram for description of an embodiment of connection to aplurality of second clients when IP addresses are included;

FIG. 52 is a flowchart of a method of controlling an electronic deviceaccording to an embodiment of the present invention;

FIG. 53 is a block diagram illustrating a main physical device and acompanion physical device according to an embodiment of the presentinvention;

FIG. 54 is a block diagram illustrating a protocol stack to support ahybrid broadcast service according to an embodiment of the presentinvention;

FIG. 55 is a view showing an UPnP type Action mechanism according to anembodiment of the present invention;

FIG. 56 is a view showing a REST mechanism according to an embodiment ofthe present invention;

FIG. 57 is a diagram illustrating a service for exchanging electronicservice guide (ESG) between a broadcast receiver and companion devicesaccording to an embodiment of the present invention;

FIG. 58 is a diagram illustrating an ESGData state variable according toan embodiment of the present invention;

FIG. 59 is a diagram illustrating an ESGData state variable according toanother embodiment of the present invention;

FIG. 60 is a diagram illustrating an operation of transmitting anESGData state variable to a companion device using an eventing methodaccording to an embodiment of the present invention;

FIG. 61 is a diagram illustrating LastChangedESGData state variableaccording to an embodiment of the present invention;

FIG. 62 is an operation of transmitting ESG data to a companion deviceaccording to a GetESGData action according to an embodiment of thepresent invention;

FIG. 63 is a diagram illustrating an operation of transmitting ESG datato a companion device according to a GetServiceIds action or aGetESGbyServiceIds action according to an embodiment of the presentinvention;

FIG. 64 is a diagram illustrating an operation of transmitting ESG datato a companion device according to a GetCurrentServiceId actionaccording to an embodiment of the present invention;

FIG. 65 is a diagram illustrating an operation of transmitting ESG datato a companion device according to a SearchESG action according to anembodiment of the present invention;

FIG. 66 is a diagram illustrating an authentication procedure oftransmitting ESG data according to a DoAuthenticationForESG actionaccording to an embodiment of the present invention;

FIG. 67 is a diagram illustrating an operation of transmitting ESG datato a companion device simultaneously with device authenticationaccording to GetServiceIds and GetESGbyServiceIds actions according toanother embodiment of the present invention;

FIG. 68 is a diagram illustrating an operation of transmitting ESG datato a companion device according to a GetService action according to anembodiment of the present invention;

FIG. 69 is a diagram illustrating a procedure of changing a service of abroadcast receiver by a companion device according to a SetChangeChannelaction according to an embodiment of the present invention;

FIG. 70 is a diagram illustrating a method of providing a broadcastservice according to an embodiment of the present invention;

FIG. 71 is a diagram of a broadcast receiver according to an embodimentof the present invention;

FIG. 72 illustrates a UPnP based PD-CD architecture according to anembodiment of the present invention;

FIG. 73 illustrates a UPnP based PD-CD architecture according to anotherembodiment of the present invention;

FIG. 74 illustrates a UPnP based PD-CD architecture according to anotherembodiment of the present invention;

FIG. 75 illustrates interactions in a UPnP based PD-CD architectureaccording to an embodiment of the present invention;

FIG. 76 illustrates a Websocket based PD-CD architecture according to anembodiment of the present invention;

FIG. 77 illustrates a Websocket based PD-CD architecture according toanother embodiment of the present invention;

FIG. 78 illustrates a Websocket based PD-CD architecture according toanother embodiment of the present invention;

FIG. 79 illustrates app-to-app communication in a Websocket based PD-CDarchitecture according to an embodiment of the present invention;

FIG. 80 illustrates an HTTP based PD-CD architecture according to anembodiment of the present invention;

FIG. 81 illustrates an HTTP based PD-CD architecture according toanother embodiment of the present invention;

FIG. 82 illustrates a Websocket & HTTP based PD-CD architectureaccording to an embodiment of the present invention;

FIG. 83 illustrates formats of messages used for discovery of a PD(Primary Device) according to an embodiment of the present invention;

FIG. 84 illustrates a process for discovering a Websocket endpoint or anHTTP service URL using a DDD (Device Description Document) according toan embodiment of the present invention;

FIG. 85 illustrates a DDD request message and a DDD format in a processfor discovering a Websocket endpoint or an HTTP service URL using a DDDaccording to an embodiment of the present invention;

FIG. 86 illustrates DDD formats in a process for discovering a Websocketendpoint or an HTTP service URL using a DDD according to an embodimentof the present invention;

FIG. 87 illustrates DDD formats in a process for discovering a Websocketendpoint or an HTTP service URL using a DDD according to anotherembodiment of the present invention;

FIG. 88 illustrates a process for discovering a Websocket endpoint or anHTTP service URL using a response header to a DDD request according toan embodiment of the present invention;

FIG. 89 illustrates response header formats in a process for discoveringa Websocket endpoint or an HTTP service URL using a response header to aDDD request according to an embodiment of the present invention;

FIG. 90 illustrates a process for discovering a Websocket endpoint or anHTTP service URL using a URL of a response header to a DDD requestaccording to an embodiment of the present invention;

FIG. 91 illustrates a GET request and formats of response messagesthereto in a process for discovering a Websocket endpoint or an HTTPservice URL using a URL of a response header to a DDD request accordingto an embodiment of the present invention;

FIG. 92 illustrates a format of a response message delivering addressinformation in a process for discovering a Websocket endpoint or an HTTPservice URL using a URL of a response header to a DDD request accordingto another embodiment of the present invention;

FIG. 93 illustrates a Websocket based handshake & connection process(after discovery) according to an embodiment of the present invention;

FIG. 94 illustrates a handshake & connection process for Websocket basedapp-to-app communication (after discovery) according to an embodiment ofthe present invention;

FIG. 95 illustrates a Websocket based two-way communication process(after connection) according to an embodiment of the present invention;

FIG. 96 illustrates a Websocket based app-to-app two-way communicationprocess (after connection/CD to PD) according to an embodiment of thepresent invention;

FIG. 97 illustrates a Websocket based app-to-app two-way communicationprocess (after connection/PD to CD) according to an embodiment of thepresent invention;

FIG. 98 illustrates an HTTP based request-response process (afterdiscovery) according to an embodiment of the present invention;

FIG. 99 illustrates a method for providing a broadcast service in a PDaccording to an embodiment of the present invention;

FIG. 100 illustrates a broadcast reception apparatus operating as a PDaccording to an embodiment of the present invention;

FIG. 101 illustrates conversion of an ESGDdata state variable in XMLformat into an ESGData state variable in JSON format according toanother embodiment of the present invention; and

FIG. 102 illustrates a process of delivering the ESGData state variablein JSON format to a companion device using a Websocket protocolaccording to another embodiment of the present invention.

FIG. 103 illustrates a hybrid broadcast reception device according to anembodiment of the present invention.

FIG. 104 is a block diagram illustrating a hybrid broadcast receiveraccording to an embodiment of the present invention.

FIG. 105 shows a protocol stack of a next generation hybrid broadcastsystem according to an embodiment of the present invention.

FIG. 106 shows a structure of a transport frame transmitted to aphysical layer of a next generation broadcast transmission systemaccording to an embodiment of the present invention.

FIG. 107 is a diagram illustrating a transport packet of an applicationlayer transmission protocol according to an embodiment of the presentinvention.

FIG. 108 illustrates a method of transmitting signaling data in a nextgeneration broadcast system according to an embodiment of the presentinvention.

FIG. 109 shows signaling data transmitted by a next generation broadcastsystem according to an embodiment of the present invention for rapidbroadcast service scan of a receiver.

FIG. 110 shows signaling data transmitted by a next generation broadcastsystem according to an embodiment of the present invention for rapidbroadcast service scan of a receiver.

FIG. 111 illustrates a method of signaling a location of service layersignaling through FIC as signaling for rapid service scan andacquisition to acquire service layer signaling from the correspondinglocation according to an embodiment of the present invention.

FIG. 112 shows signaling data transmitted by a next generation broadcastsystem according to an embodiment of the present invention for rapidbroadcast service scan of a receiver.

FIG. 113 illustrates a method of signaling a location of service layersignaling through FIC as signaling for rapid service scan andacquisition to acquire service layer signaling from the correspondinglocation according to another embodiment of the present invention.

FIG. 114 is a diagram illustrating a service signaling message format ofa next generation broadcast system according to an embodiment of thepresent invention.

FIG. 115 shows a service signaling table used in a next generationbroadcast system according to an embodiment of the present invention.

FIG. 116 is a diagram illustrating a service mapping table used in anext generation broadcast system according to an embodiment of thepresent invention.

FIG. 117 shows a service signaling table of a next generation broadcastsystem according to an embodiment of the present invention.

FIG. 118 is a diagram illustrating a component mapping table used in anext generation broadcast system according to an embodiment of thepresent invention.

FIG. 119 illustrates a component mapping table description according toan embodiment of the present invention.

FIG. 120 shows syntax of a component mapping table of a next generationbroadcast system according to an embodiment of the present invention.

FIG. 121 illustrates a method for delivering signaling associated witheach service over a broadband network in a next generation broadcastsystem according to an embodiment of the present invention.

FIG. 122 illustrates a method for signaling MPD in a next generationbroadcast system according to an embodiment of the present invention.

FIG. 123 shows syntax of an MPD delivery table of a next generationbroadcast system according to an embodiment of the present invention.

FIG. 124 shows a description of a transmission session instance of anext generation broadcast system according to an embodiment of thepresent invention.

FIG. 125 shows a SourceFlow element of a next generation broadcastsystem according to an embodiment of the present invention.

FIG. 126 shows an EFDT of a next generation broadcast system accordingto an embodiment of the present invention.

FIG. 127 shows a method for transmitting an ISDT used by a nextgeneration broadcast system according to an embodiment of the presentinvention.

FIG. 128 shows a delivery structure of a signaling message of a nextgeneration broadcast system according to an embodiment of the presentinvention.

FIG. 129 illustrates a trigger according to the aforementioned triggersyntax.

FIG. 130 illustrates the syntax of triggering application informationaccording to an embodiment of the present invention.

FIG. 131 illustrates the syntax of an event stream element including MPDaccording to an embodiment of the present invention.

FIG. 132 illustrates the syntax of an event element of an event streamelement included in the MPD according to an embodiment of the presentinvention.

FIG. 133 illustrates the syntax of an event message box for inband eventsignaling according to an embodiment of the present invention.

FIG. 134 illustrating a matching relationship of trigger attribute, theMPD element, and the event message box, for signaling trigger typeinformation, according to an embodiment of the present invention.

FIG. 135 illustrates trigger type information according to an embodimentof the present invention.

FIG. 136 illustrates the syntax of triggering application informationaccording to an embodiment of the present invention.

FIG. 137 illustrates a matching relationship of trigger attribute, theMPD element, and the event message box, for signaling a position ofinformation on a triggered application, according to an embodiment ofthe present invention.

FIG. 138 illustrates a matching relationship of trigger attribute, theMPD element, and the event message box, for signaling a status of anapplication, according to an embodiment of the present invention.

FIG. 139 is a matching relationship of trigger attribute, an MPDelement, and an event message box, for signaling an action of anapplication, according to an embodiment of the present invention.

FIG. 140 is a matching relationship of trigger attribute, an MPDelement, and an event message box, for signaling media time, accordingto an embodiment of the present invention.

FIG. 141 illustrates definition of value attribute for signaling alltrigger attributes as one event according to an embodiment of thepresent invention.

FIG. 142 illustrates a matching relationship of identifier attribute andmessage attribute of an event element, an identifier field of an eventmessage box, and a message data field, for signaling all triggerattributes as one event, according to an embodiment of the presentinvention.

FIG. 143 shows a structure of a package of an MMT protocol according toan embodiment of the present invention.

FIG. 144 shows a structure of an MMTP packet and data types included inthe MMTP packet according to an embodiment of the present invention.

FIG. 145 shows a syntax of an MMTP payload header when the MMTP packetincludes a fragment of an MPU according to an embodiment of the presentinvention.

FIG. 146 shows synchronization of content with a trigger transmittedthrough an MPU according to an embodiment of the present invention.

FIG. 147 shows a syntax of an MMT signaling message according to anotherembodiment of the present invention.

FIG. 148 shows a relationship between a value of an identifieridentifying an MMT signaling message and data signaled by the MMTsignaling message according to another embodiment of the presentinvention.

FIG. 149 shows a syntax of a signaling message including applicationsignaling information according to another embodiment of the presentinvention.

FIG. 150 shows a syntax of an application signaling table includingapplication signaling information according to another embodiment of thepresent invention.

FIG. 151 shows a relationship between trigger type information includedin an application signaling table and trigger properties included intriggers according to another embodiment of the present invention.

FIG. 152 shows a relationship between a value of an identifieridentifying an MMT signaling message and data signaled by the MMTsignaling message according to another embodiment of the presentinvention.

FIG. 153 shows a syntax of an application signaling table that does notinclude trigger type information according to another embodiment of thepresent invention.

FIG. 154 shows a structure of an MMTP packet according to anotherembodiment of the present invention.

FIG. 155 shows a structure of an MMTP packet and a syntax of a headerextension field for application signaling information transmissionaccording to another embodiment of the present invention.

FIG. 156 shows part of a broadcast system according to an embodiment ofthe present invention.

FIG. 157 shows an example in which a storage is included in a broadcastsystem according to an embodiment of the present invention.

FIG. 158 shows operation of a service worker according to an embodimentof the present invention.

FIG. 159 shows operation of a service worker in an offline stateaccording to an embodiment of the present invention.

FIG. 160 shows an application program interface (API) and metadata usedfor a receiver to execute an application according to an embodiment ofthe present invention.

FIG. 161 shows a user interface (UI) with respect to an application or alink for an application according to an embodiment of the presentinvention.

FIG. 162 shows a process through which a receiver installs and executesan application in the form of a widget according to an embodiment of thepresent invention.

FIG. 163 shows a process through which a user executes an applicationupon installation of the application according to an embodiment of thepresent invention.

FIG. 164 is a flowchart illustrating a method of executing anapplication by a broadcast receiver according to an embodiment of thepresent invention.

FIG. 165 is a diagram showing an API according to an embodiment of thepresent invention.

FIG. 166 is a diagram showing an installWidget( ) API according to anembodiment of the present invention.

FIG. 167 is a diagram showing an addWidget( ) API according to anembodiment of the present invention.

FIG. 168 is a diagram showing a getLinks( ) API according to anembodiment of the present invention.

FIG. 169 is a diagram showing a checkApplication( ) API according to anembodiment of the present invention.

FIG. 170 is a diagram showing an installWidget( ) API according to anembodiment of the present invention.

FIG. 171 is a diagram showing an addLink( ) API according to anembodiment of the present invention.

FIG. 172 is a diagram showing a broadcast transmission method accordingto an embodiment of the present invention.

FIG. 173 is a diagram showing a broadcast reception method according toan embodiment of the present invention.

BEST MODE

Reference will now be made in detail to the preferred embodiments of thepresent invention, examples of which are illustrated in the accompanyingdrawings. The detailed description, which will be given below withreference to the accompanying drawings, is intended to explain exemplaryembodiments of the present invention, rather than to show the onlyembodiments that can be implemented according to the present invention.The following detailed description includes specific details in order toprovide a thorough understanding of the present invention. However, itwill be apparent to those skilled in the art that the present inventionmay be practiced without such specific details.

Although the terms used in the present invention are selected fromgenerally known and used terms, some of the terms mentioned in thedescription of the present invention have been selected by the applicantat his or her discretion, the detailed meanings of which are describedin relevant parts of the description herein. Furthermore, it is requiredthat the present invention is understood, not simply by the actual termsused but by the meanings of each term lying within.

The present invention provides apparatuses and methods for transmittingand receiving broadcast signals for future broadcast services. Futurebroadcast services according to an embodiment of the present inventioninclude a terrestrial broadcast service, a mobile broadcast service, anultra high definition television (UHDTV) service, etc. The presentinvention may process broadcast signals for the future broadcastservices through non-MIMO (Multiple Input Multiple Output) or MIMOaccording to one embodiment. A non-MIMO scheme according to anembodiment of the present invention may include a MISO (Multiple InputSingle Output) scheme, a SISO (Single Input Single Output) scheme, etc.

FIG. 1 illustrates a receiver protocol stack according to an embodimentof the present invention.

Two schemes may be used in broadcast service delivery through abroadcast network.

In a first scheme, media processing units (MPUs) are transmitted usingan MMT protocol (MMTP) based on MPEG media transport (MMT). In a secondscheme, dynamic adaptive streaming over HTTP (DASH) segments may betransmitted using real time object delivery over unidirectionaltransport (ROUTE) based on MPEG DASH.

Non-timed content including NRT media, EPG data, and other files isdelivered with ROUTE. Signaling may be delivered over MMTP and/or ROUTE,while bootstrap signaling information is provided by the means of theService List Table (SLT).

In hybrid service delivery, MPEG DASH over HTTP/TCP/IP is used on thebroadband side. Media files in ISO Base Media File Format (BMFF) areused as the delivery, media encapsulation and synchronization format forboth broadcast and broadband delivery. Here, hybrid service delivery mayrefer to a case in which one or more program elements are deliveredthrough a broadband path.

Services are delivered using three functional layers. These are thephysical layer, the delivery layer and the service management layer. Thephysical layer provides the mechanism by which signaling, serviceannouncement and IP packet streams are transported over the broadcastphysical layer and/or broadband physical layer. The delivery layerprovides object and object flow transport functionality. It is enabledby the MMTP or the ROUTE protocol, operating on a UDP/IP multicast overthe broadcast physical layer, and enabled by the HTTP protocol on aTCP/IP unicast over the broadband physical layer. The service managementlayer enables any type of service, such as linear TV or HTML5application service, to be carried by the underlying delivery andphysical layers.

In this figure, a protocol stack part on a broadcast side may be dividedinto a part transmitted through the SLT and the MMTP, and a parttransmitted through ROUTE.

The SLT may be encapsulated through UDP and IP layers. Here, the SLTwill be described below. The MMTP may transmit data formatted in an MPUformat defined in MMT, and signaling information according to the MMTP.The data may be encapsulated through the UDP and IP layers. ROUTE maytransmit data formatted in a DASH segment form, signaling information,and non-timed data such as NRT data, etc. The data may be encapsulatedthrough the UDP and IP layers. According to a given embodiment, some orall processing according to the UDP and IP layers may be omitted. Here,the illustrated signaling information may be signaling informationrelated to a service.

The part transmitted through the SLT and the MMTP and the parttransmitted through ROUTE may be processed in the UDP and IP layers, andthen encapsulated again in a data link layer. The link layer will bedescribed below. Broadcast data processed in the link layer may bemulticast as a broadcast signal through processes such asencoding/interleaving, etc. in the physical layer.

In this figure, a protocol stack part on a broadband side may betransmitted through HTTP as described above. Data formatted in a DASHsegment form, signaling information, NRT information, etc. may betransmitted through HTTP. Here, the illustrated signaling informationmay be signaling information related to a service. The data may beprocessed through the TCP layer and the IP layer, and then encapsulatedinto the link layer. According to a given embodiment, some or all of theTCP, the IP, and the link layer may be omitted. Broadband data processedthereafter may be transmitted by unicast in the broadband through aprocess for transmission in the physical layer.

Service can be a collection of media components presented to the user inaggregate; components can be of multiple media types; a Service can beeither continuous or intermittent; a Service can be Real Time orNon-Real Time; Real Time Service can consist of a sequence of TVprograms.

FIG. 2 illustrates a relation between the SLT and SLS according to anembodiment of the present invention.

Service signaling provides service discovery and descriptioninformation, and comprises two functional components: Bootstrapsignaling via the Service List Table (SLT) and the Service LayerSignaling (SLS). These represent the information which is necessary todiscover and acquire user services. The SLT enables the receiver tobuild a basic service list, and bootstrap the discovery of the SLS foreach service.

The SLT can enable very rapid acquisition of basic service information.The SLS enables the receiver to discover and access services and theircontent components. Details of the SLT and SLS will be described below.

As described in the foregoing, the SLT may be transmitted throughUDP/IP. In this instance, according to a given embodiment, datacorresponding to the SLT may be delivered through the most robust schemein this transmission.

The SLT may have access information for accessing SLS delivered by theROUTE protocol. In other words, the SLT may be bootstrapped into SLSaccording to the ROUTE protocol. The SLS is signaling informationpositioned in an upper layer of ROUTE in the above-described protocolstack, and may be delivered through ROUTE/UDP/IP. The SLS may betransmitted through one of LCT sessions included in a ROUTE session. Itis possible to access a service component corresponding to a desiredservice using the SLS.

In addition, the SLT may have access information for accessing an MMTsignaling component delivered by MMTP. In other words, the SLT may bebootstrapped into SLS according to the MMTP. The SLS may be delivered byan MMTP signaling message defined in MMT. It is possible to access astreaming service component (MPU) corresponding to a desired serviceusing the SLS. As described in the foregoing, in the present invention,an NRT service component is delivered through the ROUTE protocol, andthe SLS according to the MMTP may include information for accessing theROUTE protocol. In broadband delivery, the SLS is carried overHTTP(S)/TCP/IP.

FIG. 3 illustrates an SLT according to an embodiment of the presentinvention.

First, a description will be given of a relation among respectivelogical entities of service management, delivery, and a physical layer.

Services may be signaled as being one of two basic types. First type isa linear audio/video or audio-only service that may have an app-basedenhancement. Second type is a service whose presentation and compositionis controlled by a downloaded application that is executed uponacquisition of the service. The latter can be called an “app-based”service.

The rules regarding presence of ROUTE/LCT sessions and/or MMTP sessionsfor carrying the content components of a service may be as follows.

For broadcast delivery of a linear service without app-basedenhancement, the service's content components can be carried by either(but not both): (1) one or more ROUTE/LCT sessions, or (2) one or moreMMTP sessions.

For broadcast delivery of a linear service with app-based enhancement,the service's content components can be carried by: (1) one or moreROUTE/LCT sessions, and (2) zero or more MMTP sessions.

In certain embodiments, use of both MMTP and ROUTE for streaming mediacomponents in the same service may not be allowed.

For broadcast delivery of an app-based service, the service's contentcomponents can be carried by one or more ROUTE/LCT sessions.

Each ROUTE session comprises one or more LCT sessions which carry as awhole, or in part, the content components that make up the service. Instreaming services delivery, an LCT session may carry an individualcomponent of a user service such as an audio, video or closed captionstream. Streaming media is formatted as DASH Segments.

Each MMTP session comprises one or more MMTP packet flows which carryMMT signaling messages or as a whole, or in part, the content component.An MMTP packet flow may carry MMT signaling messages or componentsformatted as MPUs.

For the delivery of NRT User Services or system metadata, an LCT sessioncarries file-based content items. These content files may consist ofcontinuous (time-based) or discrete (non-time-based) media components ofan NRT service, or metadata such as Service Signaling or ESG fragments.Delivery of system metadata such as service signaling or ESG fragmentsmay also be achieved through the signaling message mode of MMTP.

A broadcast stream is the abstraction for an RF channel, which isdefined in terms of a carrier frequency centered within a specifiedbandwidth. It is identified by the pair [geographic area, frequency]. Aphysical layer pipe (PLP) corresponds to a portion of the RF channel.Each PLP has certain modulation and coding parameters. It is identifiedby a PLP identifier (PLPID), which is unique within the broadcast streamit belongs to. Here, PLP can be referred to as DP (data pipe).

Each service is identified by two forms of service identifier: a compactform that is used in the SLT and is unique only within the broadcastarea; and a globally unique form that is used in the SLS and the ESG. AROUTE session is identified by a source IP address, destination IPaddress and destination port number. An LCT session (associated with theservice component(s) it carries) is identified by a transport sessionidentifier (TSI) which is unique within the scope of the parent ROUTEsession. Properties common to the LCT sessions, and certain propertiesunique to individual LCT sessions, are given in a ROUTE signalingstructure called a service-based transport session instance description(S-TSID), which is part of the service layer signaling. Each LCT sessionis carried over a single physical layer pipe. According to a givenembodiment, one LCT session may be transmitted through a plurality ofPLPs. Different LCT sessions of a ROUTE session may or may not becontained in different physical layer pipes. Here, the ROUTE session maybe delivered through a plurality of PLPs. The properties described inthe S-TSID include the TSI value and PLPID for each LCT session,descriptors for the delivery objects/files, and application layer FECparameters.

A MMTP session is identified by destination IP address and destinationport number. An MMTP packet flow (associated with the servicecomponent(s) it carries) is identified by a packet_id which is uniquewithin the scope of the parent MMTP session. Properties common to eachMMTP packet flow, and certain properties of MMTP packet flows, are givenin the SLT. Properties for each MMTP session are given by MMT signalingmessages, which may be carried within the MMTP session. Different MMTPpacket flows of a MMTP session may or may not be contained in differentphysical layer pipes. Here, the MMTP session may be delivered through aplurality of PLPs. The properties described in the MMT signalingmessages include the packet_id value and PLPID for each MMTP packetflow. Here, the MMT signaling messages may have a form defined in MMT,or have a deformed form according to embodiments to be described below.

Hereinafter, a description will be given of low level signaling (LLS).

Signaling information which is carried in the payload of IP packets witha well-known address/port dedicated to this function is referred to aslow level signaling (LLS). The IP address and the port number may bedifferently configured depending on embodiments. In one embodiment, LLScan be transported in IP packets with address 224.0.23.60 anddestination port 4937/udp. LLS may be positioned in a portion expressedby “SLT” on the above-described protocol stack. However, according to agiven embodiment, the LLS may be transmitted through a separate physicalchannel (dedicated channel) in a signal frame without being subjected toprocessing of the UDP/IP layer.

UDP/IP packets that deliver LLS data may be formatted in a form referredto as an LLS table. A first byte of each UDP/IP packet that delivers theLLS data may correspond to a start of the LLS table. The maximum lengthof any LLS table is limited by the largest IP packet that can bedelivered from the PHY layer, 65,507 bytes.

The LLS table may include an LLS table ID field that identifies a typeof the LLS table, and an LLS table version field that identifies aversion of the LLS table. According to a value indicated by the LLStable ID field, the LLS table may include the above-described SLT or arating region table (RRT). The RRT may have information about contentadvisory rating.

Hereinafter, the SLT will be described. LLS can be signaling informationwhich supports rapid channel scans and bootstrapping of serviceacquisition by the receiver, and SLT can be a table of signalinginformation which is used to build a basic service listing and providebootstrap discovery of SLS.

The function of the SLT is similar to that of the program associationtable (PAT) in MPEG-2 Systems, and the fast information channel (FIC)found in ATSC Systems. For a receiver first encountering the broadcastemission, this is the place to start. SLT supports a rapid channel scanwhich allows a receiver to build a list of all the services it canreceive, with their channel name, channel number, etc., and SLT providesbootstrap information that allows a receiver to discover the SLS foreach service. For ROUTE/DASH-delivered services, the bootstrapinformation includes the destination IP address and destination port ofthe LCT session that carries the SLS. For MMT/MPU-delivered services,the bootstrap information includes the destination IP address anddestination port of the MMTP session carrying the SLS.

The SLT supports rapid channel scans and service acquisition byincluding the following information about each service in the broadcaststream. First, the SLT can include information necessary to allow thepresentation of a service list that is meaningful to viewers and thatcan support initial service selection via channel number or up/downselection. Second, the SLT can include information necessary to locatethe service layer signaling for each service listed. That is, the SLTmay include access information related to a location at which the SLS isdelivered.

The illustrated SLT according to the present embodiment is expressed asan XML document having an SLT root element. According to a givenembodiment, the SLT may be expressed in a binary format or an XMLdocument.

The SLT root element of the SLT illustrated in the figure may include@bsid, @dltSectionVersion, @sltSectionNumber, @totalSltSectionNumbers,@language, @capabilities, InetSigLoc and/or Service. According to agiven embodiment, the SLT root element may further include @providerId.According to a given embodiment, the SLT root element may not include@language.

The service element may include @serviceId, @SLTserviceSeqNumber,@protected, @majorChannelNo, @minorChannelNo, @serviceCategory,@shortServiceName, @hidden, @slsProtocolType, BroadcastSignaling,@slsPlpId, @slsDestinationIpAddress, @slsDestinationUdpPort,@slsSourcelpAddress, @slsMajorProtocolVersion, @SlsMinorProtocolVersion,@serviceLanguage, @broadbandAccessRequired, @capabilities and/orInetSigLoc.

According to a given embodiment, an attribute or an element of the SLTmay be added/changed/deleted. Each element included in the SLT mayadditionally have a separate attribute or element, and some attribute orelements according to the present embodiment may be omitted. Here, afield which is marked with @ may correspond to an attribute, and a fieldwhich is not marked with @ may correspond to an element.

@bsid is an identifier of the whole broadcast stream. The value of BSIDmay be unique on a regional level.

@providerId can be an index of broadcaster that is using part or all ofthis broadcast stream. This is an optional attribute. When it's notpresent, it means that this broadcast stream is being used by onebroadcaster. @providerId is not illustrated in the figure.

@sltSectionVersion can be a version number of the SLT section. ThesltSectionVersion can be incremented by 1 when a change in theinformation carried within the slt occurs. When it reaches maximumvalue, it wraps around to 0.

@sltSectionNumber can be the number, counting from 1, of this section ofthe SLT. In other words, @sltSectionNumber may correspond to a sectionnumber of the SLT section. When this field is not used,@sltSectionNumber may be set to a default value of 1.

@totalSltSectionNumbers can be the total number of sections (that is,the section with the highest sltSectionNumber) of the SLT of which thissection is part. sltSectionNumber and totalSltSectionNumbers togethercan be considered to indicate “Part M of N” of one portion of the SLTwhen it is sent in fragments. In other words, when the SLT istransmitted, transmission through fragmentation may be supported. Whenthis field is not used, @totalSltSectionNumbers may be set to a defaultvalue of 1. A case in which this field is not used may correspond to acase in which the SLT is not transmitted by being fragmented.

@language can indicate primary language of the services included in thisslt instance. According to a given embodiment, a value of this field mayhave a three-character language code defined in the ISO. This field maybe omitted.

@capabilities can indicate required capabilities for decoding andmeaningfully presenting the content for all the services in this sltinstance.

InetSigLoc can provide a URL telling the receiver where it can acquireany requested type of data from external server(s) via broadband. Thiselement may include @urlType as a lower field. According to a value ofthe @urlType field, a type of a URL provided by InetSigLoc may beindicated. According to a given embodiment, when the @urlType field hasa value of 0, InetSigLoc may provide a URL of a signaling server. Whenthe @urlType field has a value of 1, InetSigLoc may provide a URL of anESG server. When the @urlType field has other values, the field may bereserved for future use.

The service field is an element having information about each service,and may correspond to a service entry. Service element fieldscorresponding to the number of services indicated by the SLT may bepresent. Hereinafter, a description will be given of a lowerattribute/element of the service field.

@serviceId can be an integer number that uniquely identify this servicewithin the scope of this broadcast area. According to a givenembodiment, a scope of @serviceId may be changed. @SLTserviceSeqNumbercan be an integer number that indicates the sequence number of the SLTservice information with service ID equal to the serviceId attributeabove. SLTserviceSeqNumber value can start at 0 for each service and canbe incremented by 1 every time any attribute in this service element ischanged. If no attribute values are changed compared to the previousService element with a particular value of ServiceID thenSLTserviceSeqNumber would not be incremented. The SLTserviceSeqNumberfield wraps back to 0 after reaching the maximum value.

@protected is flag information which may indicate whether one or morecomponents for significant reproduction of the service are in aprotected state. When set to “1” (true), that one or more componentsnecessary for meaningful presentation is protected. When set to “0”(false), this flag indicates that no components necessary for meaningfulpresentation of the service are protected. Default value is false.

@majorChannelNo is an integer number representing the “major” channelnumber of the service. An example of the field may have a range of 1 to999.

@minorChannelNo is an integer number representing the “minor” channelnumber of the service. An example of the field may have a range of 1 to999.

@serviceCategory can indicate the category of this service. This fieldmay indicate a type that varies depending on embodiments. According to agiven embodiment, when this field has values of 1, 2, and 3, the valuesmay correspond to a linear A/V service, a linear audio only service, andan app-based service, respectively. When this field has a value of 0,the value may correspond to a service of an undefined category. Whenthis field has other values except for 1, 2, and 3, the field may bereserved for future use. @shortServiceName can be a short string name ofthe Service.

@hidden can be boolean value that when present and set to “true”indicates that the service is intended for testing or proprietary use,and is not to be selected by ordinary TV receivers. The default value is“false” when not present.

@slsProtocolType can be an attribute indicating the type of protocol ofService Layer Signaling used by this service. This field may indicate atype that varies depending on embodiments. According to a givenembodiment, when this field has values of 1 and 2, protocols of SLS usedby respective corresponding services may be ROUTE and MMTP,respectively. When this field has other values except for 0, the fieldmay be reserved for future use. This field may be referred to as@slsProtocol.

BroadcastSignaling and lower attributes/elements thereof may provideinformation related to broadcast signaling. When the BroadcastSignalingelement is not present, the child element InetSigLoc of the parentservice element can be present and its attribute urlType includesURL_type 0x00 (URL to signaling server). In this case attribute urlsupports the query parameter svc=<service_id> where service_idcorresponds to the serviceId attribute for the parent service element.

Alternatively when the BroadcastSignaling element is not present, theelement InetSigLoc can be present as a child element of the slt rootelement and the attribute urlType of that InetSigLoc element includesURL_type 0x00 (URL to signaling server). In this case, attribute url forURL_type 0x00 supports the query parameter svc=<service_id> whereservice_id corresponds to the serviceId attribute for the parent Serviceelement.

@slsPlpId can be a string representing an integer number indicating thePLP ID of the physical layer pipe carrying the SLS for this service.

@slsDestinationIpAddress can be a string containing the dotted-IPv4destination address of the packets carrying SLS data for this service.

@slsDestinationUdpPort can be a string containing the port number of thepackets carrying SLS data for this service. As described in theforegoing, SLS bootstrapping may be performed by destination IP/UDPinformation.

@slsSourcelpAddress can be a string containing the dotted-IPv4 sourceaddress of the packets carrying SLS data for this service.

@slsMajorProtocolVersion can be major version number of the protocolused to deliver the service layer signaling for this service. Defaultvalue is 1.

@SlsMinorProtocolVersion can be minor version number of the protocolused to deliver the service layer signaling for this service. Defaultvalue is 0.

@serviceLanguage can be a three-character language code indicating theprimary language of the service. A value of this field may have a formthat varies depending on embodiments.

@broadbandAccessRequired can be a Boolean indicating that broadbandaccess is required for a receiver to make a meaningful presentation ofthe service. Default value is false. When this field has a value ofTrue, the receiver needs to access a broadband for significant servicereproduction, which may correspond to a case of hybrid service delivery.

@capabilities can represent required capabilities for decoding andmeaningfully presenting the content for the service with service IDequal to the service Id attribute above.

InetSigLoc can provide a URL for access to signaling or announcementinformation via broadband, if available. Its data type can be anextension of the any URL data type, adding an @urlType attribute thatindicates what the URL gives access to. An @urlType field of this fieldmay indicate the same meaning as that of the @urlType field ofInetSigLoc described above. When an InetSigLoc element of attributeURL_type 0x00 is present as an element of the SLT, it can be used tomake HTTP requests for signaling metadata. The HTTP POST message bodymay include a service term. When the InetSigLoc element appears at thesection level, the service term is used to indicate the service to whichthe requested signaling metadata objects apply. If the service term isnot present, then the signaling metadata objects for all services in thesection are requested. When the InetSigLoc appears at the service level,then no service term is needed to designate the desired service. When anInetSigLoc element of attribute URL_type 0x01 is provided, it can beused to retrieve ESG data via broadband. If the element appears as achild element of the service element, then the URL can be used toretrieve ESG data for that service. If the element appears as a childelement of the SLT element, then the URL can be used to retrieve ESGdata for all services in that section.

In another example of the SLT, @sltSectionVersion, @sltSectionNumber,@totalSltSectionNumbers and/or @language fields of the SLT may beomitted

In addition, the above-described InetSigLoc field may be replaced by@sltInetSigUri and/or @sltInetEsgUri field. The two fields may includethe URI of the signaling server and URI information of the ESG server,respectively. The InetSigLoc field corresponding to a lower field of theSLT and the InetSigLoc field corresponding to a lower field of theservice field may be replaced in a similar manner.

The suggested default values may vary depending on embodiments. Anillustrated “use” column relates to the respective fields. Here, “1” mayindicate that a corresponding field is an essential field, and “0..1”may indicate that a corresponding field is an optional field.

FIG. 4 illustrates SLS bootstrapping and a service discovery processaccording to an embodiment of the present invention.

Hereinafter, SLS will be described.

SLS can be signaling which provides information for discovery andacquisition of services and their content components.

For ROUTE/DASH, the SLS for each service describes characteristics ofthe service, such as a list of its components and where to acquire them,and the receiver capabilities required to make a meaningful presentationof the service. In the ROUTE/DASH system, the SLS includes the userservice bundle description (USBD), the S-TSID and the DASH mediapresentation description (MPD). Here, USBD or user service description(USD) is one of SLS XML fragments, and may function as a signaling herbthat describes specific descriptive information. USBD/USD may beextended beyond 3GPP MBMS. Details of USBD/USD will be described below.

The service signaling focuses on basic attributes of the service itself,especially those attributes needed to acquire the service. Properties ofthe service and programming that are intended for viewers appear asservice announcement, or ESG data.

Having separate Service Signaling for each service permits a receiver toacquire the appropriate SLS for a service of interest without the needto parse the entire SLS carried within a broadcast stream.

For optional broadband delivery of Service Signaling, the SLT caninclude HTTP URLs where the Service Signaling files can be obtained, asdescribed above.

LLS is used for bootstrapping SLS acquisition, and subsequently, the SLSis used to acquire service components delivered on either ROUTE sessionsor MMTP sessions. The described figure illustrates the followingsignaling sequences. Receiver starts acquiring the SLT described above.Each service identified by service_id delivered over ROUTE sessionsprovides SLS bootstrapping information: PLPID(#1), source IP address(sIP1), destination IP address (dIP1), and destination port number(dPort1). Each service identified by service_id delivered over MMTPsessions provides SLS bootstrapping information: PLPID(#2), destinationIP address (dIP2), and destination port number (dPort2).

For streaming services delivery using ROUTE, the receiver can acquireSLS fragments carried over the IP/UDP/LCT session and PLP; whereas forstreaming services delivery using MMTP, the receiver can acquire SLSfragments carried over an MMTP session and PLP. For service deliveryusing ROUTE, these SLS fragments include USBD/USD fragments, S-TSIDfragments, and MPD fragments. They are relevant to one service. USBD/USDfragments describe service layer properties and provide URI referencesto S-TSID fragments and URI references to MPD fragments. In other words,the USBD/USD may refer to S-TSID and MPD. For service delivery usingMMTP, the USBD references the MMT signaling's MPT message, the MP Tableof which provides identification of package ID and location informationfor assets belonging to the service. Here, an asset is a multimedia dataentity, and may refer to a data entity which is combined into one uniqueID and is used to generate one multimedia presentation. The asset maycorrespond to a service component included in one service. The MPTmessage is a message having the MP table of MMT. Here, the MP table maybe an MMT package table having information about content and an MMTasset. Details may be similar to a definition in MMT. Here, mediapresentation may correspond to a collection of data that establishesbounded/unbounded presentation of media content.

The S-TSID fragment provides component acquisition informationassociated with one service and mapping between DASH Representationsfound in the MPD and in the TSI corresponding to the component of theservice. The S-TSID can provide component acquisition information in theform of a TSI and the associated DASH representation identifier, andPLPID carrying DASH segments associated with the DASH representation. Bythe PLPID and TSI values, the receiver collects the audio/videocomponents from the service and begins buffering DASH media segmentsthen applies the appropriate decoding processes.

For USBD listing service components delivered on MMTP sessions, asillustrated by “Service #2” in the described figure, the receiver alsoacquires an MPT message with matching MMT_package_id to complete theSLS. An MPT message provides the full list of service componentscomprising a service and the acquisition information for each component.Component acquisition information includes MMTP session information, thePLPID carrying the session and the packet_id within that session.

According to a given embodiment, for example, in ROUTE, two or moreS-TSID fragments may be used. Each fragment may provide accessinformation related to LCT sessions delivering content of each service.

In ROUTE, S-TSID, USBD/USD, MPD, or an LCT session delivering S-TSID,USBD/USD or MPD may be referred to as a service signaling channel. InMMTP, USBD/UD, an MMT signaling message, or a packet flow delivering theMMTP or USBD/UD may be referred to as a service signaling channel.

Unlike the illustrated example, one ROUTE or MMTP session may bedelivered through a plurality of PLPs. In other words, one service maybe delivered through one or more PLPs. As described in the foregoing,one LCT session may be delivered through one PLP. Unlike the figure,according to a given embodiment, components included in one service maybe delivered through different ROUTE sessions. In addition, according toa given embodiment, components included in one service may be deliveredthrough different MMTP sessions. According to a given embodiment,components included in one service may be delivered separately through aROUTE session and an MMTP session. Although not illustrated, componentsincluded in one service may be delivered via broadband (hybriddelivery).

FIG. 5 illustrates a USBD fragment for ROUTE/DASH according to anembodiment of the present invention.

Hereinafter, a description will be given of SLS in delivery based onROUTE.

SLS provides detailed technical information to the receiver to enablethe discovery and access of services and their content components. Itcan include a set of XML-encoded metadata fragments carried over adedicated LCT session. That LCT session can be acquired using thebootstrap information contained in the SLT as described above. The SLSis defined on a per-service level, and it describes the characteristicsand access information of the service, such as a list of its contentcomponents and how to acquire them, and the receiver capabilitiesrequired to make a meaningful presentation of the service. In theROUTE/DASH system, for linear services delivery, the SLS consists of thefollowing metadata fragments: USBD, S-TSID and the DASH MPD. The SLSfragments can be delivered on a dedicated LCT transport session withTSI=0. According to a given embodiment, a TSI of a particular LCTsession (dedicated LCT session) in which an SLS fragment is deliveredmay have a different value. According to a given embodiment, an LCTsession in which an SLS fragment is delivered may be signaled using theSLT or another scheme.

ROUTE/DASH SLS can include the user service bundle description (USBD)and service-based transport session instance description (S-TSID)metadata fragments. These service signaling fragments are applicable toboth linear and application-based services. The USBD fragment containsservice identification, device capabilities information, references toother SLS fragments required to access the service and constituent mediacomponents, and metadata to enable the receiver to determine thetransport mode (broadcast and/or broadband) of service components. TheS-TSID fragment, referenced by the USBD, provides transport sessiondescriptions for the one or more ROUTE/LCT sessions in which the mediacontent components of a service are delivered, and descriptions of thedelivery objects carried in those LCT sessions. The USBD and S-TSID willbe described below.

In streaming content signaling in ROUTE-based delivery, a streamingcontent signaling component of SLS corresponds to an MPD fragment. TheMPD is typically associated with linear services for the delivery ofDASH Segments as streaming content. The MPD provides the resourceidentifiers for individual media components of the linear/streamingservice in the form of Segment URLs, and the context of the identifiedresources within the Media Presentation. Details of the MPD will bedescribed below.

In app-based enhancement signaling in ROUTE-based delivery, app-basedenhancement signaling pertains to the delivery of app-based enhancementcomponents, such as an application logic file, locally-cached mediafiles, network content items, or a notification stream. An applicationcan also retrieve locally-cached data over a broadband connection whenavailable.

Hereinafter, a description will be given of details of USBD/USDillustrated in the figure.

The top level or entry point SLS fragment is the USBD fragment. Anillustrated USBD fragment is an example of the present invention, basicfields of the USBD fragment not illustrated in the figure may beadditionally provided according to a given embodiment. As described inthe foregoing, the illustrated USBD fragment has an extended form, andmay have fields added to a basic configuration.

The illustrated USBD may have a bundleDescription root element. ThebundleDescription root element may have a userServiceDescriptionelement. The userServiceDescription element may correspond to aninstance for one service.

The userServiceDescription element may include @serviceId,@atsc:serviceId, @atsc:serviceStatus, @atsc:fullMPDUri, @atsc:sTSIDUri,name, serviceLanguage, atsc:capabilityCode and/or deliveryMethod.

@serviceId can be a globally unique URI that identifies a service,unique within the scope of the BSID. This parameter can be used to linkto ESG data (Service@global ServiceID).

@atsc:serviceId is a reference to corresponding service entry inLLS(SLT). The value of this attribute is the same value of serviceIdassigned to the entry.

@atsc:serviceStatus can specify the status of this service. The valueindicates whether this service is active or inactive. When set to “1”(true), that indicates service is active. When this field is not used,@atsc:serviceStatus may be set to a default value of 1.

@atsc:fullMPDUri can reference an MPD fragment which containsdescriptions for contents components of the service delivered overbroadcast and optionally, also over broadband.

@atsc:sTSIDUri can reference the S-TSID fragment which provides accessrelated parameters to the Transport sessions carrying contents of thisservice.

name can indicate name of the service as given by the lang attribute.name element can include lang attribute, which indicating language ofthe service name. The language can be specified according to XML datatypes.

serviceLanguage can represent available languages of the service. Thelanguage can be specified according to XML data types.

atsc:capabilityCode can specify the capabilities required in thereceiver to be able to create a meaningful presentation of the contentof this service. According to a given embodiment, this field may specifya predefined capability group. Here, the capability group may be a groupof capability attribute values for significant presentation. This fieldmay be omitted according to a given embodiment.

deliveryMethod can be a container of transport related informationpertaining to the contents of the service over broadcast and(optionally) broadband modes of access. Referring to data included inthe service, when the number of the data is N, delivery schemes forrespective data may be described by this element. The deliveryMethod mayinclude an r12:broadcastAppService element and an r12:unicastAppServiceelement. Each lower element may include a basePattern element as a lowerelement.

r12:broadcastAppService can be a DASH Representation delivered overbroadcast, in multiplexed or non-multiplexed form, containing thecorresponding media component(s) belonging to the service, across allPeriods of the affiliated media presentation. In other words, each ofthe fields may indicate DASH representation delivered through thebroadcast network.

r12:unicastAppService can be a DASH Representation delivered overbroadband, in multiplexed or non-multiplexed form, containing theconstituent media content component(s) belonging to the service, acrossall periods of the affiliated media presentation. In other words, eachof the fields may indicate DASH representation delivered via broadband.

basePattern can be a character pattern for use by the receiver to matchagainst any portion of the segment URL used by the DASH client torequest media segments of a parent representation under its containingperiod. A match implies that the corresponding requested media segmentis carried over broadcast transport. In a URL address for receiving DASHrepresentation expressed by each of the r12:broadcastAppService elementand the r12:unicastAppService element, a part of the URL, etc. may havea particular pattern. The pattern may be described by this field. Somedata may be distinguished using this information. The proposed defaultvalues may vary depending on embodiments. The “use” column illustratedin the figure relates to each field. Here, M may denote an essentialfield, O may denote an optional field, OD may denote an optional fieldhaving a default value, and CM may denote a conditional essential field.0 . . . 1 to 0 . . .N may indicate the number of available fields.

FIG. 6 illustrates an S-TSID fragment for ROUTE/DASH according to anembodiment of the present invention.

Hereinafter, a description will be given of the S-TSID illustrated inthe figure in detail.

S-TSID can be an SLS XML fragment which provides the overall sessiondescription information for transport session(s) which carry the contentcomponents of a service. The S-TSID is the SLS metadata fragment thatcontains the overall transport session description information for thezero or more ROUTE sessions and constituent LCT sessions in which themedia content components of a service are delivered. The S-TSID alsoincludes file metadata for the delivery object or object flow carried inthe LCT sessions of the service, as well as additional information onthe payload formats and content components carried in those LCTsessions.

Each instance of the S-TSID fragment is referenced in the USBD fragmentby the @atsc:sTSIDUri attribute of the userServiceDescription element.The illustrated S-TSID according to the present embodiment is expressedas an XML document. According to a given embodiment, the S-TSID may beexpressed in a binary format or as an XML document.

The illustrated S-TSID may have an S-TSID root element. The S-TSID rootelement may include @serviceId and/or RS.

@servicelD can be a reference corresponding service element in the USD.The value of this attribute can reference a service with a correspondingvalue of service id.

The RS element may have information about a ROUTE session for deliveringthe service data. Service data or service components may be deliveredthrough a plurality of ROUTE sessions, and thus the number of RSelements may be 1 to N.

The RS element may include @bsid, AsIpAddr, AdIpAddr, @dport, @PLPIDand/or LS.

@bsid can be an identifier of the broadcast stream within which thecontent component(s) of the broadcastAppService are carried. When thisattribute is absent, the default broadcast stream is the one whose PLPscarry SLS fragments for this service. Its value can be identical to thatof the broadcast_stream_id in the SLT.

AsIpAddr can indicate source IP address. Here, the source IP address maybe a source IP address of a ROUTE session for delivering a servicecomponent included in the service. As described in the foregoing,service components of one service may be delivered through a pluralityof ROUTE sessions. Thus, the service components may be transmitted usinganother ROUTE session other than the ROUTE session for delivering theS-TSID. Therefore, this field may be used to indicate the source IPaddress of the ROUTE session. A default value of this field may be asource IP address of a current ROUTE session. When a service componentis delivered through another ROUTE session, and thus the ROUTE sessionneeds to be indicated, a value of this field may be a value of a sourceIP address of the ROUTE session. In this case, this field may correspondto M, that is, an essential field.

AdIpAddr can indicate destination IP address. Here, a destination IPaddress may be a destination IP address of a ROUTE session that deliversa service component included in a service. For a similar case to theabove description of AsIpAddr, this field may indicate a destination IPaddress of a ROUTE session that delivers a service component. A defaultvalue of this field may be a destination IP address of a current ROUTEsession. When a service component is delivered through another ROUTEsession, and thus the ROUTE session needs to be indicated, a value ofthis field may be a value of a destination IP address of the ROUTEsession. In this case, this field may correspond to M, that is, anessential field.

@dport can indicate destination port. Here, a destination port may be adestination port of a ROUTE session that delivers a service componentincluded in a service. For a similar case to the above description ofAsIpAddr, this field may indicate a destination port of a ROUTE sessionthat delivers a service component. A default value of this field may bea destination port number of a current ROUTE session. When a servicecomponent is delivered through another ROUTE session, and thus the ROUTEsession needs to be indicated, a value of this field may be adestination port number value of the ROUTE session. In this case, thisfield may correspond to M, that is, an essential field.

@PLPID may be an ID of a PLP for a ROUTE session expressed by an RS. Adefault value may be an ID of a PLP of an LCT session including acurrent S-TSID. According to a given embodiment, this field may have anID value of a PLP for an LCT session for delivering an S-TSID in theROUTE session, and may have ID values of all PLPs for the ROUTE session.

An LS element may have information about an LCT session for delivering aservice data. Service data or service components may be deliveredthrough a plurality of LCT sessions, and thus the number of LS elementsmay be 1 to N.

The LS element may include @tsi, @PLPID, @bw, @startTime, @endTime,SrcFlow and/or RprFlow.

@tsi may indicate a TSI value of an LCT session for delivering a servicecomponent of a service.

@PLPID may have ID information of a PLP for the LCT session. This valuemay be overwritten on a basic ROUTE session value.

@bw may indicate a maximum bandwidth value. @startTime may indicate astart time of the LCT session. @endTime may indicate an end time of theLCT session. A SrcFlow element may describe a source flow of ROUTE. ARprFlow element may describe a repair flow of ROUTE.

The proposed default values may be varied according to an embodiment.The “use” column illustrated in the figure relates to each field. Here,M may denote an essential field, O may denote an optional field, OD maydenote an optional field having a default value, and CM may denote aconditional essential field. 0 . . . 1 to 0 . . . N may indicate thenumber of available fields.

Hereinafter, a description will be given of MPD for ROUTE/DASH.

The MPD is an SLS metadata fragment which contains a formalizeddescription of a DASH Media Presentation, corresponding to a linearservice of a given duration defined by the broadcaster (for example asingle TV program, or the set of contiguous linear TV programs over aperiod of time). The contents of the MPD provide the resourceidentifiers for Segments and the context for the identified resourceswithin the Media Presentation. The data structure and semantics of theMPD fragment can be according to the MPD defined by MPEG DASH.

One or more of the DASH Representations conveyed in the MPD can becarried over broadcast. The MPD may describe additional Representationsdelivered over broadband, e.g. in the case of a hybrid service, or tosupport service continuity in handoff from broadcast to broadcast due tobroadcast signal degradation (e.g. driving through a tunnel).

FIG. 7 illustrates a USBD/USD fragment for MMT according to anembodiment of the present invention.

MMT SLS for linear services comprises the USBD fragment and the MMTPackage (MP) table. The MP table is as described above. The USBDfragment contains service identification, device capabilitiesinformation, references to other SLS information required to access theservice and constituent media components, and the metadata to enable thereceiver to determine the transport mode (broadcast and/or broadband) ofthe service components. The MP table for MPU components, referenced bythe USBD, provides transport session descriptions for the MMTP sessionsin which the media content components of a service are delivered and thedescriptions of the Assets carried in those MMTP sessions.

The streaming content signaling component of the SLS for MPU componentscorresponds to the MP table defined in MMT. The MP table provides a listof MMT assets where each asset corresponds to a single service componentand the description of the location information for this component.

USBD fragments may also contain references to the S-TSID and the MPD asdescribed above, for service components delivered by the ROUTE protocoland the broadband, respectively. According to a given embodiment, indelivery through MMT, a service component delivered through the ROUTEprotocol is NRT data, etc. Thus, in this case, MPD may be unnecessary.In addition, in delivery through MMT, information about an LCT sessionfor delivering a service component, which is delivered via broadband, isunnecessary, and thus an S-TSID may be unnecessary. Here, an MMT packagemay be a logical collection of media data delivered using MMT. Here, anMMTP packet may refer to a formatted unit of media data delivered usingMMT. An MPU may refer to a generic container of independently decodabletimed/non-timed data. Here, data in the MPU is media codec agnostic.

Hereinafter, a description will be given of details of the USBD/USDillustrated in the figure.

The illustrated USBD fragment is an example of the present invention,and basic fields of the USBD fragment may be additionally providedaccording to an embodiment. As described in the foregoing, theillustrated USBD fragment has an extended form, and may have fieldsadded to a basic structure.

The illustrated USBD according to an embodiment of the present inventionis expressed as an XML document. According to a given embodiment, theUSBD may be expressed in a binary format or as an XML document.

The illustrated USBD may have a bundleDescription root element. ThebundleDescription root element may have a userServiceDescriptionelement. The userServiceDescription element may be an instance for oneservice.

The userServiceDescription element may include @serviceId,@atsc:serviceId, name, serviceLanguage, atsc:capabilityCode,atsc:Channel, atsc:mpuComponent, atsc:routeComponent,atsc:broadbandComponent and/or atsc:ComponentInfo.

Here, @serviceId, @atsc:serviceId, name, serviceLanguage, andatsc:capabilityCode may be as described above. The lang field below thename field may be as described above. atsc:capabilityCode may be omittedaccording to a given embodiment.

The userServiceDescription element may further include anatsc:contentAdvisoryRating element according to an embodiment. Thiselement may be an optional element. atsc:contentAdvisoryRating canspecify the content advisory rating. This field is not illustrated inthe figure.

atsc:Channel may have information about a channel of a service. Theatsc:Channel element may include @atsc:majorChannelNo,@atsc:minorChannelNo, @atsc:serviceLang, @atsc:serviceGenre,@atsc:serviceIcon and/or atsc:ServiceDescription. @atsc:majorChannelNo,@atsc:minorChannelNo, and @atsc:serviceLang may be omitted according toa given embodiment.

@atsc:majorChannelNo is an attribute that indicates the major channelnumber of the service.

@atsc:minorChannelNo is an attribute that indicates the minor channelnumber of the service.

@atsc:serviceLang is an attribute that indicates the primary languageused in the service.

@atsc:serviceGenre is an attribute that indicates primary genre of theservice.

@atsc:serviceIcon is an attribute that indicates the Uniform ResourceLocator (URL) for the icon used to represent this service.

atsc:ServiceDescription includes service description, possibly inmultiple languages. atsc:ServiceDescription includes can include@atsc:serviceDescrText and/or @atsc:serviceDescrLang.

@atsc:serviceDescrText is an attribute that indicates description of theservice.

@atsc:serviceDescrLang is an attribute that indicates the language ofthe serviceDescrText attribute above.

atsc:mpuComponent may have information about a content component of aservice delivered in a form of an MPU. atsc:mpuComponent may include@atsc:mmtPackageId and/or @atsc:nextMmtPackageId.

@atsc:mmtPackageId can reference a MMT Package for content components ofthe service delivered as MPUs.

@atsc:nextMmtPackageId can reference a MMT Package to be used after theone referenced by @atsc:mmtPackageId in time for content components ofthe service delivered as MPUs.

atsc:routeComponent may have information about a content component of aservice delivered through ROUTE. atsc:routeComponent may include@atsc:sTSIDUri, @sTSIDP1pId, @sTSIDDestinationIpAddress,@sTSIDDestinationUdpPort, @sTSIDSourceIpAddress,@sTSIDMajorProtocolVersion and/or @sTSIDMinorProtocolVersion.

@atsc:sTSIDUri can be a reference to the S-TSID fragment which providesaccess related parameters to the Transport sessions carrying contents ofthis service. This field may be the same as a URI for referring to anS-TSID in USBD for ROUTE described above. As described in the foregoing,in service delivery by the MMTP, service components, which are deliveredthrough NRT, etc., may be delivered by ROUTE. This field may be used torefer to the S-TSID therefor.

@sTSIDPlpId can be a string representing an integer number indicatingthe PLP ID of the physical layer pipe carrying the S-TSID for thisservice. (default: current physical layer pipe).

@sTSIDDestinationIpAddress can be a string containing the dotted-IPv4destination address of the packets carrying S-TSID for this service.(default: current MMTP session's source IP address)

@sTSIDDestinationUdpPort can be a string containing the port number ofthe packets carrying S-TSID for this service.

@sTSIDSourceIpAddress can be a string containing the dotted-IPv4 sourceaddress of the packets carrying S-TSID for this service.

@sTSIDMajorProtocolVersion can indicate major version number of theprotocol used to deliver the S-TSID for this service. Default value is1.

@sTSIDMinorProtocolVersion can indicate minor version number of theprotocol used to deliver the S-TSID for this service. Default value is0.

atsc:broadbandComponent may have information about a content componentof a service delivered via broadband. In other words,atsc:broadbandComponent may be a field on the assumption of hybriddelivery. atsc:broadbandComponent may further include @atsc:fullfMPDUri.

@atscfullfMPDUri can be a reference to an MPD fragment which containsdescriptions for contents components of the service delivered overbroadband.

An atsc:Componentlnfo field may have information about an availablecomponent of a service. The atsc:Componentlnfo field may haveinformation about a type, a role, a name, etc. of each component. Thenumber of atsc:Componentlnfo fields may correspond to the number (N) ofrespective components. The atsc:Componentlnfo field may include@atsc:componentType, @atsc:componentRole, @atsc:componentProtectedFlag,@atsc:componentId and/or @atsc:componentName.

@atsc:componentType is an attribute that indicates the type of thiscomponent. Value of 0 indicates an audio component. Value of 1 indicatesa video component. Value of 2 indicated a closed caption component.Value of 3 indicates an application component. Values 4 to 7 arereserved. A meaning of a value of this field may be differently setdepending on embodiments.

@atsc:componentRole is an attribute that indicates the role or kind ofthis component.

For audio (when componentType attribute above is equal to 0): values ofcomponentRole attribute are as follows: 0=Complete main, 1=Music andEffects, 2=Dialog, 3=Commentary, 4=Visually Impaired, 5=HearingImpaired, 6=Voice-Over, 7-254=reserved, 255=unknown.

For video (when componentType attribute above is equal to 1) values ofcomponentRole attribute are as follows: 0=Primary video, 1=Alternativecamera view, 2=Other alternative video component, 3=Sign language inset,4=Follow subject video, 5=3D video left view, 6=3D video right view,7=3D video depth information, 8=Part of video array <x,y> of <n,m>,9=Follow-Subject metadata, 10-254=reserved, 255=unknown.

For Closed Caption component (when componentType attribute above isequal to 2) values of componentRole attribute are as follows: 0=Normal,1=Easy reader, 2-254=reserved, 255=unknown.

When componentType attribute above is between 3 to 7, inclusive, thecomponentRole can be equal to 255. A meaning of a value of this fieldmay be differently set depending on embodiments.

@atsc:componentProtectedFlag is an attribute that indicates if thiscomponent is protected (e.g. encrypted). When this flag is set to avalue of 1 this component is protected (e.g. encrypted). When this flagis set to a value of 0 this component is not protected (e.g. encrypted).When not present the value of componentProtectedFlag attribute isinferred to be equal to 0. A meaning of a value of this field may bedifferently set depending on embodiments.

@atsc:componentld is an attribute that indicates the identifier of thiscomponent. The value of this attribute can be the same as the asset idin the MP table corresponding to this component.

@atsc:componentName is an attribute that indicates the human readablename of this component.

The proposed default values may vary depending on embodiments. The “use”column illustrated in the figure relates to each field. Here, M maydenote an essential field, O may denote an optional field, OD may denotean optional field having a default value, and CM may denote aconditional essential field. 0 . . . 1 to 0 . . . N may indicate thenumber of available fields.

Hereinafter, a description will be given of MPD for MMT.

The Media Presentation Description is an SLS metadata fragmentcorresponding to a linear service of a given duration defined by thebroadcaster (for example a single TV program, or the set of contiguouslinear TV programs over a period of time). The contents of the MPDprovide the resource identifiers for segments and the context for theidentified resources within the media presentation. The data structureand semantics of the MPD can be according to the MPD defined by MPEGDASH.

In the present embodiment, an MPD delivered by an MMTP session describesRepresentations delivered over broadband, e.g. in the case of a hybridservice, or to support service continuity in handoff from broadcast tobroadband due to broadcast signal degradation (e.g. driving under amountain or through a tunnel).

Hereinafter, a description will be given of an MMT signaling message forMMT.

When MMTP sessions are used to carry a streaming service, MMT signalingmessages defined by MMT are delivered by MMTP packets according tosignaling message mode defined by MMT. The value of the packet_id fieldof MMTP packets carrying service layer signaling is set to ‘00’ exceptfor MMTP packets carrying MMT signaling messages specific to an asset,which can be set to the same packet_id value as the MMTP packetscarrying the asset. Identifiers referencing the appropriate package foreach service are signaled by the USBD fragment as described above. MMTPackage Table (MPT) messages with matching MMT_package_id can bedelivered on the MMTP session signaled in the SLT. Each MMTP sessioncarries MMT signaling messages specific to its session or each assetdelivered by the MMTP session.

In other words, it is possible to access USBD of the MMTP session byspecifying an IP destination address/port number, etc. of a packethaving the SLS for a particular service in the SLT. As described in theforegoing, a packet ID of an MMTP packet carrying the SLS may bedesignated as a particular value such as 00, etc. It is possible toaccess an MPT message having a matched packet ID using theabove-described package IP information of USBD. As described below, theMPT message may be used to access each service component/asset.

The following MMTP messages can be delivered by the MMTP sessionsignaled in the SLT.

MMT Package Table (MPT) message: This message carries an MP (MMTPackage) table which contains the list of all Assets and their locationinformation as defined by MMT. If an Asset is delivered by a PLPdifferent from the current PLP delivering the MP table, the identifierof the PLP carrying the asset can be provided in the MP table usingphysical layer pipe identifier descriptor. The physical layer pipeidentifier descriptor will be described below.

MMT ATSC3 (MA3) message mmt_atsc3_message( ): This message carriessystem metadata specific for services including service layer signalingas described above. mmt_atsc3_message( ) will be described below.

The following MMTP messages can be delivered by the MMTP sessionsignaled in the SLT, if required.

Media Presentation Information (MPI) message: This message carries anMPI table which contains the whole document or a subset of a document ofpresentation information. An MP table associated with the MPI table alsocan be delivered by this message.

Clock Relation Information (CRI) message: This message carries a CRItable which contains clock related information for the mapping betweenthe NTP timestamp and the MPEG-2 STC. According to a given embodiment,the CRI message may not be delivered through the MMTP session.

The following MMTP messages can be delivered by each MMTP sessioncarrying streaming content.

Hypothetical Receiver Buffer Model message: This message carriesinformation required by the receiver to manage its buffer.

Hypothetical Receiver Buffer Model Removal message: This message carriesinformation required by the receiver to manage its MMT de-capsulationbuffer.

Hereinafter, a description will be given of mmt_atsc3_message( )corresponding to one of MMT signaling messages. An MMT Signaling messagemmt_atsc3_message( ) is defined to deliver information specific toservices according to the present invention described above. Thesignaling message may include message ID, version, and/or length fieldscorresponding to basic fields of the MMT signaling message. A payload ofthe signaling message may include service ID information, content typeinformation, content version information, content compressioninformation and/or URI information. The content type information mayindicate a type of data included in the payload of the signalingmessage. The content version information may indicate a version of dataincluded in the payload, and the content compression information mayindicate a type of compression applied to the data. The URI informationmay have URI information related to content delivered by the message.

Hereinafter, a description will be given of the physical layer pipeidentifier descriptor.

The physical layer pipe identifier descriptor is a descriptor that canbe used as one of descriptors of the MP table described above. Thephysical layer pipe identifier descriptor provides information about thePLP carrying an asset. If an asset is delivered by a PLP different fromthe current PLP delivering the MP table, the physical layer pipeidentifier descriptor can be used as an asset descriptor in theassociated MP table to identify the PLP carrying the asset. The physicallayer pipe identifier descriptor may further include BSID information inaddition to PLP ID information. The BSID may be an ID of a broadcaststream that delivers an MMTP packet for an asset described by thedescriptor.

FIG. 8 illustrates a link layer protocol architecture according to anembodiment of the present invention.

Hereinafter, a link layer will be described.

The link layer is the layer between the physical layer and the networklayer, and transports the data from the network layer to the physicallayer at the sending side and transports the data from the physicallayer to the network layer at the receiving side. The purpose of thelink layer includes abstracting all input packet types into a singleformat for processing by the physical layer, ensuring flexibility andfuture extensibility for as yet undefined input types. In addition,processing within the link layer ensures that the input data can betransmitted in an efficient manner, for example by providing options tocompress redundant information in the headers of input packets. Theoperations of encapsulation, compression and so on are referred to asthe link layer protocol and packets created using this protocol arecalled link layer packets. The link layer may perform functions such aspacket encapsulation, overhead reduction and/or signaling transmission,etc.

Hereinafter, packet encapsulation will be described. Link layer protocolallows encapsulation of any type of packet, including ones such as IPpackets and MPEG-2 TS. Using link layer protocol, the physical layerneed only process one single packet format, independent of the networklayer protocol type (here we consider MPEG-2 TS packet as a kind ofnetwork layer packet.) Each network layer packet or input packet istransformed into the payload of a generic link layer packet.Additionally, concatenation and segmentation can be performed in orderto use the physical layer resources efficiently when the input packetsizes are particularly small or large.

As described in the foregoing, segmentation may be used in packetencapsulation. When the network layer packet is too large to processeasily in the physical layer, the network layer packet is divided intotwo or more segments. The link layer packet header includes protocolfields to perform segmentation on the sending side and reassembly on thereceiving side. When the network layer packet is segmented, each segmentcan be encapsulated to link layer packet in the same order as originalposition in the network layer packet. Also each link layer packet whichincludes a segment of network layer packet can be transported to PHYlayer consequently.

As described in the foregoing, concatenation may be used in packetencapsulation. When the network layer packet is small enough for thepayload of a link layer packet to include several network layer packets,the link layer packet header includes protocol fields to performconcatenation. The concatenation is combining of multiple small sizednetwork layer packets into one payload. When the network layer packetsare concatenated, each network layer packet can be concatenated topayload of link layer packet in the same order as original input order.Also each packet which constructs a payload of link layer packet can bewhole packet, not a segment of packet.

Hereinafter, overhead reduction will be described. Use of the link layerprotocol can result in significant reduction in overhead for transportof data on the physical layer. The link layer protocol according to thepresent invention may provide IP overhead reduction and/or MPEG-2 TSoverhead reduction. In IP overhead reduction, IP packets have a fixedheader format, however some of the information which is needed in acommunication environment may be redundant in a broadcast environment.Link layer protocol provides mechanisms to reduce the broadcast overheadby compressing headers of IP packets. In MPEG-2 TS overhead reduction,link layer protocol provides sync byte removal, null packet deletionand/or common header removal (compression). First, sync byte removalprovides an overhead reduction of one byte per TS packet, secondly anull packet deletion mechanism removes the 188 byte null TS packets in amanner that they can be re-inserted at the receiver and finally a commonheader removal mechanism.

For signaling transmission, in the link layer protocol, a particularformat for the signaling packet may be provided for link layersignaling, which will be described below.

In the illustrated link layer protocol architecture according to anembodiment of the present invention, link layer protocol takes as inputnetwork layer packets such as IPv4, MPEG-2 TS and so on as inputpackets. Future extension indicates other packet types and protocolwhich is also possible to be input in link layer. Link layer protocolalso specifies the format and signaling for any link layer signaling,including information about mapping to specific channel to the physicallayer. Figure also shows how ALP incorporates mechanisms to improve theefficiency of transmission, via various header compression and deletionalgorithms. In addition, the link layer protocol may basicallyencapsulate input packets.

FIG. 9 illustrates a structure of a base header of a link layer packetaccording to an embodiment of the present invention. Hereinafter, thestructure of the header will be described.

A link layer packet can include a header followed by the data payload.The header of a link layer packet can include a base header, and mayinclude an additional header depending on the control fields of the baseheader. The presence of an optional header is indicated from flag fieldsof the additional header. According to a given embodiment, a fieldindicating the presence of an additional header and an optional headermay be positioned in the base header.

Hereinafter, the structure of the base header will be described. Thebase header for link layer packet encapsulation has a hierarchicalstructure. The base header can be two bytes in length and is the minimumlength of the link layer packet header.

The illustrated base header according to the present embodiment mayinclude a Packet_Type field, a PC field and/or a length field. Accordingto a given embodiment, the base header may further include an HM fieldor an S/C field.

Packet_Type field can be a 3-bit field that indicates the originalprotocol or packet type of the input data before encapsulation into alink layer packet. An IPv4 packet, a compressed IP packet, a link layersignaling packet, and other types of packets may have the base headerstructure and may be encapsulated. However, according to a givenembodiment, the MPEG-2 TS packet may have a different particularstructure, and may be encapsulated. When the value of Packet_Type is“000”, “001” “100” or “111”, that is the original data type of an ALPpacket is one of an IPv4 packet, a compressed IP packet, link layersignaling or extension packet. When the MPEG-2 TS packet isencapsulated, the value of Packet_Type can be “010”. Other values of thePacket_Type field may be reserved for future use.

Payload_Configuration (PC) field can be a 1-bit field that indicates theconfiguration of the payload. A value of 0 can indicate that the linklayer packet carries a single, whole input packet and the followingfield is the Header_Mode field. A value of 1 can indicate that the linklayer packet carries more than one input packet (concatenation) or apart of a large input packet (segmentation) and the following field isthe Segmentation Concatenation field.

Header_Mode (HM) field can be a 1-bit field, when set to 0, that canindicate there is no additional header, and that the length of thepayload of the link layer packet is less than 2048 bytes. This value maybe varied depending on embodiments. A value of 1 can indicate that anadditional header for single packet defined below is present followingthe Length field. In this case, the length of the payload is larger than2047 bytes and/or optional features can be used (sub streamidentification, header extension, etc.). This value may be varieddepending on embodiments. This field can be present only whenPayload_Configuration field of the link layer packet has a value of 0.

Segmentation_Concatenation (S/C) field can be a 1-bit field, when set to0, that can indicate that the payload carries a segment of an inputpacket and an additional header for segmentation defined below ispresent following the Length field. A value of 1 can indicate that thepayload carries more than one complete input packet and an additionalheader for concatenation defined below is present following the Lengthfield. This field can be present only when the value ofPayload_Configuration field of the ALP packet is 1.

Length field can be an 11-bit field that indicates the 11 leastsignificant bits (LSBs) of the length in bytes of payload carried by thelink layer packet. When there is a Length_MSB field in the followingadditional header, the length field is concatenated with the Length_MSBfield, and is the LSB to provide the actual total length of the payload.The number of bits of the length field may be changed to another valuerather than 11 bits.

Following types of packet configuration are thus possible: a singlepacket without any additional header, a single packet with an additionalheader, a segmented packet and a concatenated packet. According to agiven embodiment, more packet configurations may be made through acombination of each additional header, an optional header, an additionalheader for signaling information to be described below, and anadditional header for time extension.

FIG. 10 illustrates a structure of an additional header of a link layerpacket according to an embodiment of the present invention.

Various types of additional headers may be present. Hereinafter, adescription will be given of an additional header for a single packet.

This additional header for single packet can be present when Header_Mode(HM)=“1”. The Header_Mode (HM) can be set to 1 when the length of thepayload of the link layer packet is larger than 2047 bytes or when theoptional fields are used. The additional header for single packet isshown in Figure (tsib10010).

Length_MSB field can be a 5-bit field that can indicate the mostsignificant bits (MSBs) of the total payload length in bytes in thecurrent link layer packet, and is concatenated with the Length fieldcontaining the 11 least significant bits (LSBs) to obtain the totalpayload length. The maximum length of the payload that can be signaledis therefore 65535 bytes. The number of bits of the length field may bechanged to another value rather than 11 bits. In addition, the number ofbits of the Length_MSB field may be changed, and thus a maximumexpressible payload length may be changed. According to a givenembodiment, each length field may indicate a length of a whole linklayer packet rather than a payload.

SIF (Sub stream Identifier Flag) field can be a 1-bit field that canindicate whether the sub stream ID (SID) is present after the HEF fieldor not. When there is no SID in this link layer packet, SIF field can beset to 0. When there is a SID after HEF field in the link layer packet,SIF can be set to 1. The detail of SID is described below.

HEF (Header Extension Flag) field can be a 1-bit field that canindicate, when set to 1 additional header is present for futureextension. A value of 0 can indicate that this extension header is notpresent.

Hereinafter, a description will be given of an additional header whensegmentation is used.

This additional header (tsib10020) can be present when SegmentationConcatenation (S/C)=“0”. Segment Sequence Number can be a 5-bit unsignedinteger that can indicate the order of the corresponding segment carriedby the link layer packet. For the link layer packet which carries thefirst segment of an input packet, the value of this field can be set to0x0. This field can be incremented by one with each additional segmentbelonging to the segmented input packet.

Last_Segment_Indicator (LSI) can be a 1-bit field that can indicate,when set to 1, that the segment in this payload is the last one of inputpacket. A value of 0, can indicate that it is not last segment.

SIF (Sub stream Identifier Flag) can be a 1-bit field that can indicatewhether the SID is present after the HEF field or not. When there is noSID in the link layer packet, SIF field can be set to 0. When there is aSID after the HEF field in the link layer packet, SIF can be set to 1.

HEF (Header Extension Flag) can be a This 1-bit field that can indicate,when set to 1, that the optional header extension is present after theadditional header for future extensions of the link layer header. Avalue of 0 can indicate that optional header extension is not present.

According to a given embodiment, a packet ID field may be additionallyprovided to indicate that each segment is generated from the same inputpacket. This field may be unnecessary and thus be omitted when segmentsare transmitted in order.

Hereinafter, a description will be given of an additional header whenconcatenation is used.

This additional header (tsib10030) can be present whenSegmentation_Concatenation (S/C)=“1”.

Length_MSB can be a 4-bit field that can indicate MSB bits of thepayload length in bytes in this link layer packet. The maximum length ofthe payload is 32767 bytes for concatenation. As described in theforegoing, a specific numeric value may be changed.

Count can be a field that can indicate the number of the packetsincluded in the link layer packet. The number of the packets included inthe link layer packet, 2 can be set to this field. So, its maximum valueof concatenated packets in a link layer packet is 9. A scheme in whichthe count field indicates the number may be varied depending onembodiments. That is, the numbers from 1 to 8 may be indicated.

HEF (Header Extension Flag) can be a 1-bit field that can indicate, whenset to 1 the optional header extension is present after the additionalheader for future extensions of the link layer header. A value of 0, canindicate extension header is not present.

Component_Length can be a 12-bit length field that can indicate thelength in byte of each packet. Component_Length fields are included inthe same order as the packets present in the payload except lastcomponent packet. The number of length field can be indicated by(Count+1). According to a given embodiment, length fields, the number ofwhich is the same as a value of the count field, may be present. When alink layer header consists of an odd number of Component_Length, fourstuffing bits can follow after the last Component_Length field. Thesebits can be set to 0. According to a given embodiment, aComponent_length field indicating a length of a last concatenated inputpacket may not be present. In this case, the length of the lastconcatenated input packet may correspond to a length obtained bysubtracting a sum of values indicated by respective Component_lengthfields from a whole payload length.

Hereinafter, the optional header will be described.

As described in the foregoing, the optional header may be added to arear of the additional header. The optional header field can contain SIDand/or header extension. The SID is used to filter out specific packetstream in the link layer level. One example of SID is the role ofservice identifier in a link layer stream carrying multiple services.The mapping information between a service and the SID valuecorresponding to the service can be provided in the SLT, if applicable.The header extension contains extended field for future use. Receiverscan ignore any header extensions which they do not understand.

SID (Sub stream Identifier) can be an 8-bit field that can indicate thesub stream identifier for the link layer packet. If there is optionalheader extension, SID present between additional header and optionalheader extension.

Header_Extension ( ) can include the fields defined below.

Extension_Type can be an 8-bit field that can indicate the type of theHeader_Extension ( ).

Extension_Length can be an 8-bit field that can indicate the length ofthe Header Extension ( ) in bytes counting from the next byte to thelast byte of the Header Extension ( ).

Extension_Byte can be a byte representing the value of theHeader_Extension ( ).

FIG. 11 illustrates a structure of an additional header of a link layerpacket according to another embodiment of the present invention.

Hereinafter, a description will be given of an additional header forsignaling information.

How link layer signaling is incorporated into link layer packets are asfollows. Signaling packets are identified by when the Packet Type fieldof the base header is equal to 100.

Figure (tsib11010) shows the structure of the link layer packetscontaining additional header for signaling information. In addition tothe link layer header, the link layer packet can consist of twoadditional parts, additional header for signaling information and theactual signaling data itself. The total length of the link layersignaling packet is shown in the link layer packet header.

The additional header for signaling information can include followingfields. According to a given embodiment, some fields may be omitted.

Signaling_Type can be an 8-bit field that can indicate the type ofsignaling.

Signaling_Type_Extension can be a 16-bit filed that can indicate theattribute of the signaling. Detail of this field can be defined insignaling specification.

Signaling_Version can be an 8-bit field that can indicate the version ofsignaling.

Signaling_Format can be a 2-bit field that can indicate the data formatof the signaling data. Here, a signaling format may refer to a dataformat such as a binary format, an XML format, etc.

Signaling_Encoding can be a 2-bit field that can specify theencoding/compression format. This field may indicate whether compressionis not performed and which type of compression is performed.

Hereinafter, a description will be given of an additional header forpacket type extension.

In order to provide a mechanism to allow an almost unlimited number ofadditional protocol and packet types to be carried by link layer in thefuture, the additional header is defined. Packet type extension can beused when Packet_type is 111 in the base header as described above.Figure (tsib11020) shows the structure of the link layer packetscontaining additional header for type extension.

The additional header for type extension can include following fields.According to a given embodiment, some fields may be omitted.

extended_type can be a 16-bit field that can indicate the protocol orpacket type of the input encapsulated in the link layer packet aspayload. This field cannot be used for any protocol or packet typealready defined by Packet_Type field.

FIG. 12 illustrates a header structure of a link layer packet for anMPEG-2 TS packet and an encapsulation process thereof according to anembodiment of the present invention.

Hereinafter, a description will be given of a format of the link layerpacket when the MPEG-2 TS packet is input as an input packet.

In this case, the Packet_Type field of the base header is equal to 010.Multiple TS packets can be encapsulated within each link layer packet.The number of TS packets is signaled via the NUMTS field. In this case,as described in the foregoing, a particular link layer packet headerformat may be used.

Link layer provides overhead reduction mechanisms for MPEG-2 TS toenhance the transmission efficiency. The sync byte (0x47) of each TSpacket can be deleted. The option to delete NULL packets and similar TSheaders is also provided.

In order to avoid unnecessary transmission overhead, TS null packets(PID=0x1FFF) may be removed. Deleted null packets can be recovered inreceiver side using DNP field. The DNP field indicates the count ofdeleted null packets. Null packet deletion mechanism using DNP field isdescribed below.

In order to achieve more transmission efficiency, similar header ofMPEG-2 TS packets can be removed. When two or more successive TS packetshave sequentially increased continuity counter fields and other headerfields are the same, the header is sent once at the first packet and theother headers are deleted. HDM field can indicate whether the headerdeletion is performed or not. Detailed procedure of common TS headerdeletion is described below.

When all three overhead reduction mechanisms are performed, overheadreduction can be performed in sequence of sync removal, null packetdeletion, and common header deletion. According to a given embodiment, aperformance order of respective mechanisms may be changed. In addition,some mechanisms may be omitted according to a given embodiment.

The overall structure of the link layer packet header when using MPEG-2TS packet encapsulation is depicted in Figure (tsib12010).

Hereinafter, a description will be given of each illustrated field.Packet_Type can be a 3-bit field that can indicate the protocol type ofinput packet as describe above. For MPEG-2 TS packet encapsulation, thisfield can always be set to 010.

NUMTS (Number of TS packets) can be a 4-bit field that can indicate thenumber of TS packets in the payload of this link layer packet. A maximumof 16 TS packets can be supported in one link layer packet. The value ofNUMTS=0 can indicate that 16 TS packets are carried by the payload ofthe link layer packet. For all other values of NUMTS, the same number ofTS packets are recognized, e.g. NUMTS=0001 means one TS packet iscarried.

AHF (Additional Header Flag) can be a field that can indicate whetherthe additional header is present of not. A value of 0 indicates thatthere is no additional header. A value of 1 indicates that an additionalheader of length 1-byte is present following the base header. If null TSpackets are deleted or TS header compression is applied this field canbe set to 1. The additional header for TS packet encapsulation consistsof the following two fields and is present only when the value of AHF inthis link layer packet is set to 1.

HDM (Header Deletion Mode) can be a 1-bit field that indicates whetherTS header deletion can be applied to this link layer packet. A value of1 indicates that TS header deletion can be applied. A value of “0”indicates that the TS header deletion method is not applied to this linklayer packet.

DNP (Deleted Null Packets) can be a 7-bit field that indicates thenumber of deleted null TS packets prior to this link layer packet. Amaximum of 128 null TS packets can be deleted. When HDM=0 the value ofDNP=0 can indicate that 128 null packets are deleted. When HDM=1 thevalue of DNP=0 can indicate that no null packets are deleted. For allother values of DNP, the same number of null packets are recognized,e.g. DNP=5 means 5 null packets are deleted.

The number of bits of each field described above may be changed.According to the changed number of bits, a minimum/maximum value of avalue indicated by the field may be changed. These numbers may bechanged by a designer.

Hereinafter, SYNC byte removal will be described.

When encapsulating TS packets into the payload of a link layer packet,the SYNC byte (0x47) from the start of each TS packet can be deleted.Hence the length of the MPEG2-TS packet encapsulated in the payload ofthe link layer packet is always of length 187 bytes (instead of 188bytes originally).

Hereinafter, null packet deletion will be described.

Transport Stream rules require that bit rates at the output of atransmitter's multiplexer and at the input of the receiver'sde-multiplexer are constant in time and the end-to-end delay is alsoconstant. For some Transport Stream input signals, null packets may bepresent in order to accommodate variable bitrate services in a constantbitrate stream. In this case, in order to avoid unnecessary transmissionoverhead, TS null packets (that is TS packets with PID=0x1FFF) may beremoved. The process is carried-out in a way that the removed nullpackets can be re-inserted in the receiver in the exact place where theywere originally, thus guaranteeing constant bitrate and avoiding theneed for PCR time stamp updating.

Before generation of a link layer packet, a counter called DNP (DeletedNull-Packets) can first be reset to zero and then incremented for eachdeleted null packet preceding the first non-null TS packet to beencapsulated into the payload of the current link layer packet. Then agroup of consecutive useful TS packets is encapsulated into the payloadof the current link layer packet and the value of each field in itsheader can be determined. After the generated link layer packet isinjected to the physical layer, the DNP is reset to zero. When DNPreaches its maximum allowed value, if the next packet is also a nullpacket, this null packet is kept as a useful packet and encapsulatedinto the payload of the next link layer packet. Each link layer packetcan contain at least one useful TS packet in its payload.

Hereinafter, TS packet header deletion will be described. TS packetheader deletion may be referred to as TS packet header compression.

When two or more successive TS packets have sequentially increasedcontinuity counter fields and other header fields are the same, theheader is sent once at the first packet and the other headers aredeleted. When the duplicated MPEG-2 TS packets are included in two ormore successive TS packets, header deletion cannot be applied intransmitter side. HDM field can indicate whether the header deletion isperformed or not. When TS header deletion is performed, HDM can be setto 1. In the receiver side, using the first packet header, the deletedpacket headers are recovered, and the continuity counter is restored byincreasing it in order from that of the first header.

An example tsib12020 illustrated in the figure is an example of aprocess in which an input stream of a TS packet is encapsulated into alink layer packet. First, a TS stream including TS packets having SYNCbyte (0x47) may be input. First, sync bytes may be deleted through async byte deletion process. In this example, it is presumed that nullpacket deletion is not performed.

Here, it is presumed that packet headers of eight TS packets have thesame field values except for CC, that is, a continuity counter fieldvalue. In this case, TS packet deletion/compression may be performed.Seven remaining TS packet headers are deleted except for a first TSpacket header corresponding to CC=1. The processed TS packets may beencapsulated into a payload of the link layer packet.

In a completed link layer packet, a Packet Type field corresponds to acase in which TS packets are input, and thus may have a value of 010. ANUMTS field may indicate the number of encapsulated TS packets. An AHFfield may be set to 1 to indicate the presence of an additional headersince packet header deletion is performed. An HDM field may be set to 1since header deletion is performed. DNP may be set to 0 since nullpacket deletion is not performed.

FIG. 13 illustrates an example of adaptation modes in IP headercompression according to an embodiment of the present invention(transmitting side).

Hereinafter, IP header compression will be described.

In the link layer, IP header compression/decompression scheme can beprovided. IP header compression can include two parts: headercompressor/decompressor and adaptation module. The header compressionscheme can be based on the Robust Header Compression (RoHC). Inaddition, for broadcasting usage, adaptation function is added.

In the transmitter side, ROHC compressor reduces the size of header foreach packet. Then, adaptation module extracts context information andbuilds signaling information from each packet stream. In the receiverside, adaptation module parses the signaling information associated withthe received packet stream and attaches context information to thereceived packet stream. ROHC decompressor reconstructs the original IPpacket by recovering the packet header.

The header compression scheme can be based on the RoHC as describedabove. In particular, in the present system, an RoHC framework canoperate in a unidirctional mode (U mode) of the RoHC. In addition, inthe present system, it is possible to use an RoHC UDP header compressionprofile which is identified by a profile identifier of 0x0002.

Hereinafter, adaptation will be described.

In case of transmission through the unidirectional link, if a receiverhas no information of context, decompressor cannot recover the receivedpacket header until receiving full context. This may cause channelchange delay and turn on delay. For this reason, context information andconfiguration parameters between compressor and decompressor can bealways sent with packet flow.

The Adaptation function provides out-of-band transmission of theconfiguration parameters and context information. Out-of-bandtransmission can be done through the link layer signaling. Therefore,the adaptation function is used to reduce the channel change delay anddecompression error due to loss of context information.

Hereinafter, extraction of context information will be described.

Context information may be extracted using various schemes according toadaptation mode. In the present invention, three examples will bedescribed below. The scope of the present invention is not restricted tothe examples of the adaptation mode to be described below. Here, theadaptation mode may be referred to as a context extraction mode.

Adaptation Mode 1 (not illustrated) may be a mode in which no additionaloperation is applied to a basic RoHC packet stream. In other words, theadaptation module may operate as a buffer in this mode. Therefore, inthis mode, context information may not be included in link layersignaling

In Adaptation Mode 2 (tsib13010), the adaptation module can detect theIR packet from ROHC packet flow and extract the context information(static chain). After extracting the context information, each IR packetcan be converted to an IR-DYN packet. The converted IR-DYN packet can beincluded and transmitted inside the ROHC packet flow in the same orderas IR packet, replacing the original packet.

In Adaptation Mode 3 (tsib13020), the adaptation module can detect theIR and IR-DYN packet from ROHC packet flow and extract the contextinformation. The static chain and dynamic chain can be extracted from IRpacket and dynamic chain can be extracted from IR-DYN packet. Afterextracting the context information, each IR and IR-DYN packet can beconverted to a compressed packet. The compressed packet format can bethe same with the next packet of IR or IR-DYN packet. The convertedcompressed packet can be included and transmitted inside the ROHC packetflow in the same order as IR or IR-DYN packet, replacing the originalpacket.

Signaling (context) information can be encapsulated based ontransmission structure. For example, context information can beencapsulated to the link layer signaling. In this case, the packet typevalue can be set to “100”.

In the above-described Adaptation Modes 2 and 3, a link layer packet forcontext information may have a packet type field value of 100. Inaddition, a link layer packet for compressed IP packets may have apacket type field value of 001. The values indicate that each of thesignaling information and the compressed IP packets are included in thelink layer packet as described above.

Hereinafter, a description will be given of a method of transmitting theextracted context information.

The extracted context information can be transmitted separately fromROHC packet flow, with signaling data through specific physical datapath. The transmission of context depends on the configuration of thephysical layer path. The context information can be sent with other linklayer signaling through the signaling data pipe.

In other words, the link layer packet having the context information maybe transmitted through a signaling PLP together with link layer packetshaving other link layer signaling information (Packet Type=100).Compressed IP packets from which context information is extracted may betransmitted through a general PLP (Packet_Type=001). Here, depending onembodiments, the signaling PLP may refer to an L1 signaling path. Inaddition, depending on embodiments, the signaling PLP may not beseparated from the general PLP, and may refer to a particular andgeneral PLP through which the signaling information is transmitted.

At a receiving side, prior to reception of a packet stream, a receivermay need to acquire signaling information. When receiver decodes initialPLP to acquire the signaling information, the context signaling can bealso received. After the signaling acquisition is done, the PLP toreceive packet stream can be selected. In other words, the receiver mayacquire the signaling information including the context information byselecting the initial PLP. Here, the initial PLP may be theabove-described signaling PLP. Thereafter, the receiver may select a PLPfor acquiring a packet stream. In this way, the context information maybe acquired prior to reception of the packet stream.

After the PLP for acquiring the packet stream is selected, theadaptation module can detect IR-DYN packet form received packet flow.Then, the adaptation module parses the static chain from the contextinformation in the signaling data. This is similar to receiving the IRpacket. For the same context identifier, IR-DYN packet can be recoveredto IR packet. Recovered ROHC packet flow can be sent to ROHCdecompressor. Thereafter, decompression may be started.

FIG. 14 illustrates a link mapping table (LMT) and an RoHC-U descriptiontable according to an embodiment of the present invention.

Hereinafter, link layer signaling will be described.

Generally, link layer signaling is operates under IP level. At thereceiver side, link layer signaling can be obtained earlier than IPlevel signaling such as Service List Table (SLT) and Service LayerSignaling (SLS). Therefore, link layer signaling can be obtained beforesession establishment.

For link layer signaling, there can be two kinds of signaling accordinginput path: internal link layer signaling and external link layersignaling. The internal link layer signaling is generated in link layerat transmitter side. And the link layer takes the signaling fromexternal module or protocol. This kind of signaling information isconsidered as external link layer signaling. If some signaling need tobe obtained prior to IP level signaling, external signaling istransmitted in format of link layer packet.

The link layer signaling can be encapsulated into link layer packet asdescribed above. The link layer packets can carry any format of linklayer signaling, including binary and XML. The same signalinginformation may not be transmitted in different formats for the linklayer signaling.

Internal link layer signaling may include signaling information for linkmapping. The Link Mapping Table (LMT) provides a list of upper layersessions carried in a PLP. The LMT also provides addition informationfor processing the link layer packets carrying the upper layer sessionsin the link layer.

An example of the LMT (tsib14010) according to the present invention isillustrated.

signaling_type can be an 8-bit unsigned integer field that indicates thetype of signaling carried by this table. The value of signaling_typefield for Link Mapping Table (LMT) can be set to 0x01.

PLP_ID can be an 8-bit field that indicates the PLP corresponding tothis table.

num_session can be an 8-bit unsigned integer field that provides thenumber of upper layer sessions carried in the PLP identified by theabove PLP_ID field. When the value of signaling_type field is 0x01, thisfield can indicate the number of UDP/IP sessions in the PLP.

src_IP_add can be a 32-bit unsigned integer field that contains thesource IP address of an upper layer session carried in the PLPidentified by the PLP_ID field.

dst_IP_add can be a 32-bit unsigned integer field that contains thedestination IP address of an upper layer session carried in the PLPidentified by the PLP_ID field.

src_UDP_port can be a 16-bit unsigned integer field that represents thesource UDP port number of an upper layer session carried in the PLPidentified by the PLP_ID field.

dst_UDP_port can be a 16-bit unsigned integer field that represents thedestination UDP port number of an upper layer session carried in the PLPidentified by the PLP_ID field.

SID_flag can be a 1-bit Boolean field that indicates whether the linklayer packet carrying the upper layer session identified by above 4fields, Src_IP_add, Dst_IP_add, Src_UDP_Port and Dst_UDPP_Port, has anSID field in its optional header. When the value of this field is set to0, the link layer packet carrying the upper layer session may not havean SID field in its optional header. When the value of this field is setto 1, the link layer packet carrying the upper layer session can have anSID field in its optional header and the value the SID field can be sameas the following SID field in this table.

compressed_flag can be a 1-bit Boolean field that indicates whether theheader compression is applied the link layer packets carrying the upperlayer session identified by above 4 fields, Src_IP_add, Dst_IP_add,Src_UDP_Port and Dst_UDP_Port. When the value of this field is set to 0,the link layer packet carrying the upper layer session may have a valueof 0x00 of Packet_Type field in its base header. When the value of thisfield is set to 1, the link layer packet carrying the upper layersession may have a value of 0x01 of Packet_Type field in its base headerand the Context_ID field can be present.

SID can be an 8-bit unsigned integer field that indicates sub streamidentifier for the link layer packets carrying the upper layer sessionidentified by above 4 fields, Src_IP_add, Dst_IP_add, Src_UDP_Port andDst_UDP_Port. This field can be present when the value of SID_flag isequal to 1.

context_id can be an 8-bit field that provides a reference for thecontext id (CID) provided in the ROHC-U description table. This fieldcan be present when the value of compressed_flag is equal to 1.

An example of the RoHC-U description table (tsib14020) according to thepresent invention is illustrated. As described in the foregoing, theRoHC-U adaptation module may generate information related to headercompression.

signaling_type can be an 8-bit field that indicates the type ofsignaling carried by this table. The value of signaling_type field forROHC-U description table (RDT) can be set to “0x02”.

PLP_ID can be an 8-bit field that indicates the PLP corresponding tothis table.

context_id can be an 8-bit field that indicates the context id (CID) ofthe compressed IP stream. In this system, 8-bit CID can be used forlarge CID.

context_profile can be an 8-bit field that indicates the range ofprotocols used to compress the stream. This field can be omitted.

adaptation_mode can be a 2-bit field that indicates the mode ofadaptation module in this PLP. Adaptation modes have been describedabove.

context_config can be a 2-bit field that indicates the combination ofthe context information. If there is no context information in thistable, this field may be set to “0x0”. If the static_chain( ) ordynamic_chain( ) byte is included in this table, this field may be setto “0x01” or “0x02” respectively. If both of the static_chain( ) anddynamic_chain( ) byte are included in this table, this field may be setto “0x03”.

context_length can be an 8-bit field that indicates the length of thestatic chain byte sequence. This field can be omitted.

static_chain_byte 0 can be a field that conveys the static informationused to initialize the ROHC-U decompressor. The size and structure ofthis field depend on the context profile.

dynamic_chain_byte 0 can be a field that conveys the dynamic informationused to initialize the ROHC-U decompressor. The size and structure ofthis field depend on the context profile.

The static_chain_byte can be defined as sub-header information of IRpacket. The dynamic_chain_byte can be defined as sub-header informationof IR packet and IR-DYN packet.

FIG. 15 illustrates a structure of a link layer on a transmitter sideaccording to an embodiment of the present invention.

The present embodiment presumes that an IP packet is processed. From afunctional point of view, the link layer on the transmitter side maybroadly include a link layer signaling part in which signalinginformation is processed, an overhead reduction part, and/or anencapsulation part. In addition, the link layer on the transmitter sidemay include a scheduler for controlling and scheduling an overalloperation of the link layer and/or input and output parts of the linklayer.

First, signaling information of an upper layer and/or a system parametertsib15010 may be delivered to the link layer. In addition, an IP streamincluding IP packets may be delivered to the link layer from an IP layertsib15110.

As described above, the scheduler tsib15020 may determine and controloperations of several modules included in the link layer. The deliveredsignaling information and/or system parameter tsib15010 may be faltereror used by the scheduler tsib15020. Information, which corresponds to apart of the delivered signaling information and/or system parametertsib15010, necessary for a receiver may be delivered to the link layersignaling part. In addition, information, which corresponds to a part ofthe signaling information, necessary for an operation of the link layermay be delivered to an overhead reduction controller tsib15120 or anencapsulation controller tsib15180.

The link layer signaling part may collect information to be transmittedas a signal in a physical layer, and convert/configure the informationin a form suitable for transmission. The link layer signaling part mayinclude a signaling manager tsib15030, a signaling formatter tsib15040,and/or a buffer for channels tsib15050.

The signaling manager tsib15030 may receive signaling informationdelivered from the scheduler tsib15020 and/or signaling (and/or context)information delivered from the overhead reduction part. The signalingmanager tsib15030 may determine a path for transmission of the signalinginformation for delivered data. The signaling information may bedelivered through the path determined by the signaling managertsib15030. As described in the foregoing, signaling information to betransmitted through a divided channel such as the FIC, the EAS, etc. maybe delivered to the signaling formatter tsib15040, and other signalinginformation may be delivered to an encapsulation buffer tsib15070.

The signaling formatter tsib15040 may format related signalinginformation in a form suitable for each divided channel such thatsignaling information may be transmitted through a separately dividedchannel. As described in the foregoing, the physical layer may includeseparate physically/logically divided channels. The divided channels maybe used to transmit FIC signaling information or EAS-relatedinformation. The FIC or EAS-related information may be sorted by thesignaling manager tsib15030, and input to the signaling formattertsib15040. The signaling formatter tsib15040 may format the informationbased on each separate channel. When the physical layer is designed totransmit particular signaling information through a separately dividedchannel other than the FIC and the EAS, a signaling formatter for theparticular signaling information may be additionally provided. Throughthis scheme, the link layer may be compatible with various physicallayers.

The buffer for channels tsib15050 may deliver the signaling informationreceived from the signaling formatter tsib15040 to separate dedicatedchannels tsib15060. The number and content of the separate channels mayvary depending on embodiments.

As described in the foregoing, the signaling manager tsib15030 maydeliver signaling information, which is not delivered to a particularchannel, to the encapsulation buffer tsib15070. The encapsulation buffertsib15070 may function as a buffer that receives the signalinginformation which is not delivered to the particular channel.

An encapsulation block for signaling information tsib15080 mayencapsulate the signaling information which is not delivered to theparticular channel. A transmission buffer tsib15090 may function as abuffer that delivers the encapsulated signaling information to a DP forsignaling information tsib15100. Here, the DP for signaling informationtsib15100 may refer to the above-described PLS region.

The overhead reduction part may allow efficient transmission by removingoverhead of packets delivered to the link layer. It is possible toconfigure overhead reduction parts corresponding to the number of IPstreams input to the link layer.

An overhead reduction buffer tsib15130 may receive an IP packetdelivered from an upper layer. The received IP packet may be input tothe overhead reduction part through the overhead reduction buffertsib15130.

An overhead reduction controller tsib15120 may determine whether toperform overhead reduction on a packet stream input to the overheadreduction buffer tsib15130. The overhead reduction controller tsib15120may determine whether to perform overhead reduction for each packetstream. When overhead reduction is performed on a packet stream, packetsmay be delivered to a robust header compression (RoHC) compressortsib15140 to perform overhead reduction. When overhead reduction is notperformed on a packet stream, packets may be delivered to theencapsulation part to perform encapsulation without overhead reduction.Whether to perform overhead reduction of packets may be determined basedon the signaling information tsib15010 delivered to the link layer. Thesignaling information may be delivered to the encapsulation controllertsib15180 by the scheduler tsib15020.

The RoHC compressor tsib15140 may perform overhead reduction on a packetstream. The RoHC compressor tsib15140 may perform an operation ofcompressing a header of a packet. Various schemes may be used foroverhead reduction. Overhead reduction may be performed using a schemeproposed by the present invention. The present invention presumes an IPstream, and thus an expression “RoHC compressor” is used. However, thename may be changed depending on embodiments. The operation is notrestricted to compression of the IP stream, and overhead reduction ofall types of packets may be performed by the RoHC compressor tsib15140.

A packet stream configuration block tsib15150 may separate informationto be transmitted to a signaling region and information to betransmitted to a packet stream from IP packets having compressedheaders. The information to be transmitted to the packet stream mayrefer to information to be transmitted to a DP region. The informationto be transmitted to the signaling region may be delivered to asignaling and/or context controller tsib15160. The information to betransmitted to the packet stream may be transmitted to the encapsulationpart.

The signaling and/or context controller tsib15160 may collect signalingand/or context information and deliver the signaling and/or contextinformation to the signaling manager in order to transmit the signalingand/or context information to the signaling region.

The encapsulation part may perform an operation of encapsulating packetsin a form suitable for a delivery to the physical layer. It is possibleto configure encapsulation parts corresponding to the number of IPstreams.

An encapsulation buffer tsib15170 may receive a packet stream forencapsulation. Packets subjected to overhead reduction may be receivedwhen overhead reduction is performed, and an input IP packet may bereceived without change when overhead reduction is not performed.

An encapsulation controller tsib15180 may determine whether toencapsulate an input packet stream. When encapsulation is performed, thepacket stream may be delivered to a segmentation/concatenation blocktsib15190. When encapsulation is not performed, the packet stream may bedelivered to a transmission buffer tsib15230. Whether to encapsulatepackets may be determined based on the signaling information tsib15010delivered to the link layer. The signaling information may be deliveredto the encapsulation controller tsib15180 by the scheduler tsib15020.

In the segmentation/concatenation block tsib15190, the above-describedsegmentation or concatenation operation may be performed on packets. Inother words, when an input IP packet is longer than a link layer packetcorresponding to an output of the link layer, one IP packet may besegmented into several segments to configure a plurality of link layerpacket payloads. On the other hand, when an input IP packet is shorterthan a link layer packet corresponding to an output of the link layer,several IP packets may be concatenated to configure one link layerpacket payload.

A packet configuration table tsib15200 may have configurationinformation of a segmented and/or concatenated link layer packet. Atransmitter and a receiver may have the same information in the packetconfiguration table tsib15200. The transmitter and the receiver mayrefer to the information of the packet configuration table tsib15200. Anindex value of the information of the packet configuration tabletsib15200 may be included in a header of the link layer packet.

A link layer header information block tsib15210 may collect headerinformation generated in an encapsulation process. In addition, the linklayer header information block tsib15210 may collect header informationincluded in the packet configuration table tsib15200. The link layerheader information block tsib15210 may configure header informationaccording to a header structure of the link layer packet.

A header attachment block tsib15220 may add a header to a payload of asegmented and/or concatenated link layer packet. The transmission buffertsib15230 may function as a buffer to deliver the link layer packet to aDP tsib15240 of the physical layer.

The respective blocks, modules, or parts may be configured as onemodule/protocol or a plurality of modules/protocols in the link layer.

FIG. 16 illustrates a structure of a link layer on a receiver sideaccording to an embodiment of the present invention.

The present embodiment presumes that an IP packet is processed. From afunctional point of view, the link layer on the receiver side maybroadly include a link layer signaling part in which signalinginformation is processed, an overhead processing part, and/or adecapsulation part. In addition, the link layer on the receiver side mayinclude a scheduler for controlling and scheduling overall operation ofthe link layer and/or input and output parts of the link layer.

First, information received through a physical layer may be delivered tothe link layer. The link layer may process the information, restore anoriginal state before being processed at a transmitter side, and thendeliver the information to an upper layer. In the present embodiment,the upper layer may be an IP layer.

Information, which is separated in the physical layer and deliveredthrough a particular channel tsib16030, may be delivered to a link layersignaling part. The link layer signaling part may determine signalinginformation received from the physical layer, and deliver the determinedsignaling information to each part of the link layer.

A buffer for channels tsib16040 may function as a buffer that receivessignaling information transmitted through particular channels. Asdescribed in the foregoing, when physically/logically divided separatechannels are present in the physical layer, it is possible to receivesignaling information transmitted through the channels. When theinformation received from the separate channels is segmented, thesegmented information may be stored until complete information isconfigured.

A signaling decoder/parser tsib16050 may verify a format of thesignaling information received through the particular channel, andextract information to be used in the link layer. When the signalinginformation received through the particular channel is encoded, decodingmay be performed. In addition, according to a given embodiment, it ispossible to verify integrity, etc. of the signaling information.

A signaling manager tsib16060 may integrate signaling informationreceived through several paths. Signaling information received through aDP for signaling tsib16070 to be described below may be integrated inthe signaling manager tsib16060. The signaling manager tsib16060 maydeliver signaling information necessary for each part in the link layer.For example, the signaling manager tsibl 6060 may deliver contextinformation, etc. for recovery of a packet to the overhead processingpart. In addition, the signaling manager tsib16060 may deliver signalinginformation for control to a scheduler tsib16020.

General signaling information, which is not received through a separateparticular channel, may be received through the DP for signalingtsib16070. Here, the DP for signaling may refer to PLS, L1, etc. Here,the DP may be referred to as a PLP. A reception buffer tsib16080 mayfunction as a buffer that receives signaling information delivered fromthe DP for signaling. In a decapsulation block for signaling informationtsib16090, the received signaling information may be decapsulated. Thedecapsulated signaling information may be delivered to the signalingmanager tsib16060 through a decapsulation buffer tsib16100. As describedin the foregoing, the signaling manager tsib16060 may collate signalinginformation, and deliver the collated signaling information to anecessary part in the link layer.

The scheduler tsib16020 may determine and control operations of severalmodules included in the link layer. The scheduler tsib16020 may controleach part of the link layer using receiver information tsib16010 and/orinformation delivered from the signaling manager tsib16060. In addition,the scheduler tsib16020 may determine an operation mode, etc. of eachpart. Here, the receiver information tsib16010 may refer to informationpreviously stored in the receiver. The scheduler tsib16020 may useinformation changed by a user such as channel switching, etc. to performa control operation.

The decapsulation part may filter a packet received from a DP tsib16110of the physical layer, and separate a packet according to a type of thepacket. It is possible to configure decapsulation parts corresponding tothe number of DPs that can be simultaneously decoded in the physicallayer.

The decapsulation buffer tsib16100 may function as a buffer thatreceives a packet stream from the physical layer to performdecapsulation. A decapsulation controller tsib16130 may determinewhether to decapsulate an input packet stream. When decapsulation isperformed, the packet stream may be delivered to a link layer headerparser tsib16140. When decapsulation is not performed, the packet streammay be delivered to an output buffer tsib16220. The signalinginformation received from the scheduler tsib16020 may be used todetermine whether to perform decapsulation.

The link layer header parser tsib16140 may identify a header of thedelivered link layer packet. It is possible to identify a configurationof an IP packet included in a payload of the link layer packet byidentifying the header. For example, the IP packet may be segmented orconcatenated.

A packet configuration table tsib16150 may include payload informationof segmented and/or concatenated link layer packets. The transmitter andthe receiver may have the same information in the packet configurationtable tsibl 6150. The transmitter and the receiver may refer to theinformation of the packet configuration table tsib16150. It is possibleto find a value necessary for reassembly based on index informationincluded in the link layer packet.

A reassembly block tsib16160 may configure payloads of the segmentedand/or concatenated link layer packets as packets of an original IPstream. Segments may be collected and reconfigured as one IP packet, orconcatenated packets may be separated and reconfigured as a plurality ofIP packet streams. Recombined IP packets may be delivered to theoverhead processing part.

The overhead processing part may perform an operation of restoring apacket subjected to overhead reduction to an original packet as areverse operation of overhead reduction performed in the transmitter.This operation may be referred to as overhead processing. It is possibleto configure overhead processing parts corresponding to the number ofDPs that can be simultaneously decoded in the physical layer.

A packet recovery buffer tsib16170 may function as a buffer thatreceives a decapsulated RoHC packet or IP packet to perform overheadprocessing.

An overhead controller tsib16180 may determine whether to recover and/ordecompress the decapsulated packet. When recovery and/or decompressionare performed, the packet may be delivered to a packet stream recoveryblock tsib16190. When recovery and/or decompression are not performed,the packet may be delivered to the output buffer tsib16220. Whether toperform recovery and/or decompression may be determined based on thesignaling information delivered by the scheduler tsib16020.

The packet stream recovery block tsib16190 may perform an operation ofintegrating a packet stream separated from the transmitter with contextinformation of the packet stream. This operation may be a process ofrestoring a packet stream such that an RoHC decompressor tsib16210 canperform processing. In this process, it is possible to receive signalinginformation and/or context information from a signaling and/or contextcontroller tsib16200. The signaling and/or context controller tsib16200may determine signaling information delivered from the transmitter, anddeliver the signaling information to the packet stream recovery blocktsib16190 such that the signaling information may be mapped to a streamcorresponding to a context ID.

The RoHC decompressor tsib16210 may restore headers of packets of thepacket stream. The packets of the packet stream may be restored to formsof original IP packets through restoration of the headers. In otherwords, the RoHC decompressor tsib16210 may perform overhead processing.

The output buffer tsib16220 may function as a buffer before an outputstream is delivered to an IP layer tsib16230.

The link layers of the transmitter and the receiver proposed in thepresent invention may include the blocks or modules described above. Inthis way, the link layer may independently operate irrespective of anupper layer and a lower layer, overhead reduction may be efficientlyperformed, and a supportable function according to an upper/lower layermay be easily defined/added/deleted.

FIG. 17 illustrates a configuration of signaling transmission through alink layer according to an embodiment of the present invention(transmitting/receiving sides).

In the present invention, a plurality of service providers(broadcasters) may provide services within one frequency band. Inaddition, a service provider may provide a plurality of services, andone service may include one or more components. It can be consideredthat the user receives content using a service as a unit.

The present invention presumes that a transmission protocol based on aplurality of sessions is used to support an IP hybrid broadcast.Signaling information delivered through a signaling path may bedetermined based on a transmission configuration of each protocol.Various names may be applied to respective protocols according to agiven embodiment.

In the illustrated data configuration tsib17010 on the transmittingside, service providers (broadcasters) may provide a plurality ofservices (Service #1, #2, . . . ). In general, a signal for a servicemay be transmitted through a general transport session (signaling C).However, the signal may be transmitted through a particular session(dedicated session) according to a given embodiment (signaling B).

Service data and service signaling information may be encapsulatedaccording to a transmission protocol. According to a given embodiment,an IP/UDP layer may be used. According to a given embodiment, a signalin the IP/UDP layer (signaling A) may be additionally provided. Thissignaling may be omitted.

Data processed using the IP/UDP may be input to the link layer. Asdescribed in the foregoing, overhead reduction and/or encapsulation maybe performed in the link layer. Here, link layer signaling may beadditionally provided. Link layer signaling may include a systemparameter, etc. Link layer signaling has been described above.

The service data and the signaling information subjected to the aboveprocess may be processed through PLPs in a physical layer. Here, a PLPmay be referred to as a DP. The example illustrated in the figurepresumes a case in which a base DP/PLP is used. However, depending onembodiments, transmission may be performed using only a general DP/PLPwithout the base DP/PLP.

In the example illustrated in the figure, a particular channel(dedicated channel) such as an FIC, an EAC, etc. is used. A signaldelivered through the FIC may be referred to as a fast information table(FIT), and a signal delivered through the EAC may be referred to as anemergency alert table (EAT). The FIT may be identical to theabove-described SLT. The particular channels may not be used dependingon embodiments. When the particular channel (dedicated channel) is notconfigured, the FIT and the EAT may be transmitted using a general linklayer signaling transmission scheme, or transmitted using a PLP via theIP/UDP as other service data.

According to a given embodiment, system parameters may include atransmitter-related parameter, a service provider-related parameter,etc. Link layer signaling may include IP header compression-relatedcontext information and/or identification information of data to whichthe context is applied. Signaling of an upper layer may include an IPaddress, a UDP number, service/component information, emergencyalert-related information, an IP/UDP address for service signaling, asession ID, etc. Detailed examples thereof have been described above.

In the illustrated data configuration tsib17020 on the receiving side,the receiver may decode only a PLP for a corresponding service usingsignaling information without having to decode all PLPs.

First, when the user selects or changes a service desired to bereceived, the receiver may be tuned to a corresponding frequency and mayread receiver information related to a corresponding channel stored in aDB, etc. The information stored in the DB, etc. of the receiver may beconfigured by reading an SLT at the time of initial channel scan.

After receiving the SLT and the information about the correspondingchannel, information previously stored in the DB is updated, andinformation about a transmission path of the service selected by theuser and information about a path, through which component informationis acquired or a signal necessary to acquire the information istransmitted, are acquired. When the information is not determined to bechanged using version information of the SLT, decoding or parsing may beomitted.

The receiver may verify whether SLT information is included in a PLP byparsing physical signaling of the PLP in a corresponding broadcaststream (not illustrated), which may be indicated through a particularfield of physical signaling. It is possible to access a position atwhich a service layer signal of a particular service is transmitted byaccessing the SLT information. The service layer signal may beencapsulated into the IP/UDP and delivered through a transport session.It is possible to acquire information about a component included in theservice using this service layer signaling. A specific SLT-SLSconfiguration is as described above.

In other words, it is possible to acquire transmission path information,for receiving upper layer signaling information (service signalinginformation) necessary to receive the service, corresponding to one ofseveral packet streams and PLPs currently transmitted on a channel usingthe SLT. The transmission path information may include an IP address, aUDP port number, a session ID, a PLP ID, etc. Here, depending onembodiments, a value previously designated by the IANA or a system maybe used as an IP/UDP address. The information may be acquired using ascheme of accessing a DB or a shared memory, etc.

When the link layer signal and service data are transmitted through thesame PLP, or only one PLP is operated, service data delivered throughthe PLP may be temporarily stored in a device such as a buffer, etc.while the link layer signal is decoded.

It is possible to acquire information about a path through which theservice is actually transmitted using service signaling information of aservice to be received. In addition, a received packet stream may besubjected to decapsulation and header recovery using information such asoverhead reduction for a PLP to be received, etc.

In the illustrated example (tsib17020), the FIC and the EAC are used,and a concept of the base DP/PLP is presumed. As described in theforegoing, concepts of the FIC, the EAC, and the base DP/PLP may not beused.

While MISO or MIMO uses two antennas in the following for convenience ofdescription, the present invention is applicable to systems using two ormore antennas. The present invention proposes a physical profile (orsystem) optimized to minimize receiver complexity while attaining theperformance required for a particular use case. Physical (PHY) profiles(base, handheld and advanced profiles) according to an embodiment of thepresent invention are subsets of all configurations that a correspondingreceiver should implement. The PHY profiles share most of the functionalblocks but differ slightly in specific blocks and/or parameters. For thesystem evolution, future profiles may also be multiplexed with existingprofiles in a single radio frequency (RF) channel through a futureextension frame (FEF). The base profile and the handheld profileaccording to the embodiment of the present invention refer to profilesto which MIMO is not applied, and the advanced profile refers to aprofile to which MIMO is applied. The base profile may be used as aprofile for both the terrestrial broadcast service and the mobilebroadcast service. That is, the base profile may be used to define aconcept of a profile which includes the mobile profile. In addition, theadvanced profile may be divided into an advanced profile for a baseprofile with MIMO and an advanced profile for a handheld profile withMIMO. Moreover, the profiles may be changed according to intention ofthe designer.

The following terms and definitions may be applied to the presentinvention. The following terms and definitions may be changed accordingto design.

Auxiliary stream: sequence of cells carrying data of as yet undefinedmodulation and coding, which may be used for future extensions or asrequired by broadcasters or network operators

Base data pipe: data pipe that carries service signaling data

Baseband frame (or BBFRAME): set of Kbch bits which form the input toone FEC encoding process (BCH and LDPC encoding)

Cell: modulation value that is carried by one carrier of orthogonalfrequency division multiplexing (OFDM) transmission

Coded block: LDPC-encoded block of PLS1 data or one of the LDPC-encodedblocks of PLS2 data

Data pipe: logical channel in the physical layer that carries servicedata or related metadata, which may carry one or a plurality ofservice(s) or service component(s).

Data pipe unit (DPU): a basic unit for allocating data cells to a DP ina frame.

Data symbol: OFDM symbol in a frame which is not a preamble symbol (thedata symbol encompasses the frame signaling symbol and frame edgesymbol)

DP_ID: this 8-bit field identifies uniquely a DP within the systemidentified by the SYSTEM_ID

Dummy cell: cell carrying a pseudo-random value used to fill theremaining capacity not used for PLS signaling, DPs or auxiliary streams

Emergency alert channel (EAC): part of a frame that carries EASinformation data

Frame: physical layer time slot that starts with a preamble and endswith a frame edge symbol

Frame repetition unit: a set of frames belonging to the same ordifferent physical layer profiles including an FEF, which is repeatedeight times in a superframe

Fast information channel (FIC): a logical channel in a frame thatcarries mapping information between a service and the corresponding baseDP

FECBLOCK: set of LDPC-encoded bits of DP data

FFT size: nominal FFT size used for a particular mode, equal to theactive symbol period Ts expressed in cycles of an elementary period T

Frame signaling symbol: OFDM symbol with higher pilot density used atthe start of a frame in certain combinations of FFT size, guard intervaland scattered pilot pattern, which carries a part of the PLS data

Frame edge symbol: OFDM symbol with higher pilot density used at the endof a frame in certain combinations of FFT size, guard interval andscattered pilot pattern

Frame group: the set of all frames having the same PHY profile type in asuperframe

Future extension frame: physical layer time slot within the superframethat may be used for future extension, which starts with a preamble

Futurecast UTB system: proposed physical layer broadcast system, theinput of which is one or more MPEG2-TS, IP or general stream(s) and theoutput of which is an RF signal

Input stream: a stream of data for an ensemble of services delivered tothe end users by the system

Normal data symbol: data symbol excluding the frame signaling symbol andthe frame edge symbol

PHY profile: subset of all configurations that a corresponding receivershould implement

PLS: physical layer signaling data including PLS1 and PLS2

PLS1: a first set of PLS data carried in a frame siganling symbol (FSS)having a fixed size, coding and modulation, which carries basicinformation about a system as well as parameters needed to decode PLS2

NOTE: PLS1 data remains constant for the duration of a frame group

PLS2: a second set of PLS data transmitted in the FSS, which carriesmore detailed PLS data about the system and the DPs

PLS2 dynamic data: PLS2 data that dynamically changes frame-by-frame

PLS2 static data: PLS2 data that remains static for the duration of aframe group

Preamble signaling data: signaling data carried by the preamble symboland used to identify the basic mode of the system

Preamble symbol: fixed-length pilot symbol that carries basic PLS dataand is located at the beginning of a frame

The preamble symbol is mainly used for fast initial band scan to detectthe system signal, timing thereof, frequency offset, and FFT size.

Reserved for future use: not defined by the present document but may bedefined in future

Superframe: set of eight frame repetition units

Time interleaving block (TI block): set of cells within which timeinterleaving is carried out, corresponding to one use of a timeinterleaver memory

TI group: unit over which dynamic capacity allocation for a particularDP is carried out, made up of an integer, dynamically varying number ofXFECBLOCKs

NOTE: The TI group may be mapped directly to one frame or may be mappedto a plurality of frames. The TI group may contain one or more TIblocks.

Type 1 DP: DP of a frame where all DPs are mapped to the frame in timedivision multiplexing (TDM) scheme

Type 2 DP: DP of a frame where all DPs are mapped to the frame infrequency division multiplexing (FDM) scheme

XFECBLOCK: set of N_(cells) cells carrying all the bits of one LDPCFECBLOCK

FIG. 18 illustrates a configuration of a broadcast signal transmissionapparatus for future broadcast services according to an embodiment ofthe present invention.

The broadcast signal transmission apparatus for future broadcastservices according to the present embodiment may include an inputformatting block 1000, a bit interleaved coding & modulation (BICM)block 1010, a frame building block 1020, an OFDM generation block 1030and a signaling generation block 1040. Description will be given of anoperation of each block of the broadcast signal transmission apparatus.

In input data according to an embodiment of the present invention, IPstream/packets and MPEG2-TS may be main input formats, and other streamtypes are handled as general streams. In addition to these data inputs,management information is input to control scheduling and allocation ofthe corresponding bandwidth for each input stream. In addition, thepresent invention allows simultaneous input of one or a plurality of TSstreams, IP stream(s) and/or a general stream(s).

The input formatting block 1000 may demultiplex each input stream intoone or a plurality of data pipes, to each of which independent codingand modulation are applied. A DP is the basic unit for robustnesscontrol, which affects QoS. One or a plurality of services or servicecomponents may be carried by one DP. The DP is a logical channel in aphysical layer for delivering service data or related metadata capableof carrying one or a plurality of services or service components.

In addition, a DPU is a basic unit for allocating data cells to a DP inone frame.

An input to the physical layer may include one or a plurality of datastreams. Each of the data streams is delivered by one DP. The inputformatting block 1000 may covert a data stream input through one or morephysical paths (or DPs) into a baseband frame (BBF). In this case, theinput formatting block 1000 may perform null packet deletion or headercompression on input data (a TS or IP input stream) in order to enhancetransmission efficiency. A receiver may have a priori information for aparticular part of a header, and thus this known information may bedeleted from a transmitter. A null packet deletion block 3030 may beused only for a TS input stream.

In the BICM block 1010, parity data is added for error correction andencoded bit streams are mapped to complex-value constellation symbols.The symbols are interleaved across a specific interleaving depth that isused for the corresponding DP. For the advanced profile, MIMO encodingis performed in the BICM block 1010 and an additional data path is addedat the output for MIMO transmission.

The frame building block 1020 may map the data cells of the input DPsinto the OFDM symbols within a frame, and perform frequency interleavingfor frequency-domain diversity, especially to combat frequency-selectivefading channels. The frame building block 1020 may include a delaycompensation block, a cell mapper and a frequency interleaver.

The delay compensation block may adjust timing between DPs andcorresponding PLS data to ensure that the DPs and the corresponding PLSdata are co-timed at a transmitter side. The PLS data is delayed by thesame amount as the data pipes by addressing the delays of data pipescaused by the input formatting block and BICM block. The delay of theBICM block is mainly due to the time interleaver. In-band signaling datacarries information of the next TI group so that the information iscarried one frame ahead of the DPs to be signaled. The delaycompensation block delays in-band signaling data accordingly.

The cell mapper may map PLS, DPs, auxiliary streams, dummy cells, etc.to active carriers of the OFDM symbols in the frame. The basic functionof the cell mapper 7010 is to map data cells produced by the TIs foreach of the DPs, PLS cells, and EAC/FIC cells, if any, into arrays ofactive OFDM cells corresponding to each of the OFDM symbols within aframe. A basic function of the cell mapper is to map a data cellgenerated by time interleaving for each DP and PLS cell to an array ofactive OFDM cells (if present) corresponding to respective OFDM symbolsin one frame. Service signaling data (such as program specificinformation (PSI)/SI) may be separately gathered and sent by a DP. Thecell mapper operates according to dynamic information produced by ascheduler and the configuration of a frame structure. The frequencyinterleaver may randomly interleave data cells received from the cellmapper to provide frequency diversity. In addition, the frequencyinterleaver may operate on an OFDM symbol pair including two sequentialOFDM symbols using a different interleaving-seed order to obtain maximuminterleaving gain in a single frame.

The OFDM generation block 1030 modulates OFDM carriers by cells producedby the frame building block, inserts pilots, and produces a time domainsignal for transmission. In addition, this block subsequently insertsguard intervals, and applies peak-to-average power ratio (PAPR)reduction processing to produce a final RF signal.

Specifically, after inserting a preamble at the beginning of each frame,the OFDM generation block 1030 may apply conventional OFDM modulationhaving a cyclic prefix as a guard interval. For antenna space diversity,a distributed MISO scheme is applied across transmitters. In addition, aPAPR scheme is performed in the time domain. For flexible networkplanning, the present invention provides a set of various FFT sizes,guard interval lengths and corresponding pilot patterns.

In addition, the present invention may multiplex signals of a pluralityof broadcast transmission/reception systems in the time domain such thatdata of two or more different broadcast transmission/reception systemsproviding broadcast services may be simultaneously transmitted in thesame RF signal bandwidth. In this case, the two or more differentbroadcast transmission/reception systems refer to systems providingdifferent broadcast services. The different broadcast services may referto a terrestrial broadcast service, mobile broadcast service, etc.

The signaling generation block 1040 may create physical layer signalinginformation used for an operation of each functional block. Thissignaling information is also transmitted so that services of interestare properly recovered at a receiver side. Signaling informationaccording to an embodiment of the present invention may include PLSdata. PLS provides the receiver with a means to access physical layerDPs. The PLS data includes PLS1 data and PLS2 data.

The PLS1 data is a first set of PLS data carried in an FSS symbol in aframe having a fixed size, coding and modulation, which carries basicinformation about the system in addition to the parameters needed todecode the PLS2 data. The PLS1 data provides basic transmissionparameters including parameters required to enable reception anddecoding of the PLS2 data. In addition, the PLS1 data remains constantfor the duration of a frame group.

The PLS2 data is a second set of PLS data transmitted in an FSS symbol,which carries more detailed PLS data about the system and the DPs. ThePLS2 contains parameters that provide sufficient information for thereceiver to decode a desired DP. The PLS2 signaling further includes twotypes of parameters, PLS2 static data (PLS2-STAT data) and PLS2 dynamicdata (PLS2-DYN data). The PLS2 static data is PLS2 data that remainsstatic for the duration of a frame group and the PLS2 dynamic data isPLS2 data that dynamically changes frame by frame. Details of the PLSdata will be described later.

The above-described blocks may be omitted or replaced by blocks havingsimilar or identical functions.

FIG. 19 illustrates a BICM block according to an embodiment of thepresent invention.

The BICM block illustrated in FIG. 19 corresponds to an embodiment ofthe BICM block 1010 described with reference to FIG. 18.

As described above, the broadcast signal transmission apparatus forfuture broadcast services according to the embodiment of the presentinvention may provide a terrestrial broadcast service, mobile broadcastservice, UHDTV service, etc.

Since QoS depends on characteristics of a service provided by thebroadcast signal transmission apparatus for future broadcast servicesaccording to the embodiment of the present invention, data correspondingto respective services needs to be processed using different schemes.Accordingly, the BICM block according to the embodiment of the presentinvention may independently process respective DPs by independentlyapplying SISO, MISO and MIMO schemes to data pipes respectivelycorresponding to data paths. Consequently, the broadcast signaltransmission apparatus for future broadcast services according to theembodiment of the present invention may control QoS for each service orservice component transmitted through each DP.

(a) shows a BICM block applied to a profile (or system) to which MIMO isnot applied, and (b) shows a BICM block of a profile (or system) towhich MIMO is applied.

The BICM block to which MIMO is not applied and the BICM block to whichMIMO is applied may include a plurality of processing blocks forprocessing each DP.

Description will be given of each processing block of the BICM block towhich MIMO is not applied and the BICM block to which MIMO is applied.

A processing block 5000 of the BICM block to which MIMO is not appliedmay include a data FEC encoder 5010, a bit interleaver 5020, aconstellation mapper 5030, a signal space diversity (SSD) encoding block5040 and a time interleaver 5050.

The data FEC encoder 5010 performs FEC encoding on an input BBF togenerate FECBLOCK procedure using outer coding (BCH) and inner coding(LDPC). The outer coding (BCH) is optional coding method. A detailedoperation of the data FEC encoder 5010 will be described later.

The bit interleaver 5020 may interleave outputs of the data FEC encoder5010 to achieve optimized performance with a combination of LDPC codesand a modulation scheme while providing an efficiently implementablestructure. A detailed operation of the bit interleaver 5020 will bedescribed later.

The constellation mapper 5030 may modulate each cell word from the bitinterleaver 5020 in the base and the handheld profiles, or each cellword from the cell-word demultiplexer 5010-1 in the advanced profileusing either QPSK, QAM-16, non-uniform QAM (NUQ-64, NUQ-256, orNUQ-1024) or non-uniform constellation (NUC-16, NUC-64, NUC-256, orNUC-1024) mapping to give a power-normalized constellation point, e₁.This constellation mapping is applied only for DPs. It is observed thatQAM-16 and NUQs are square shaped, while NUCs have arbitrary shapes.When each constellation is rotated by any multiple of 90 degrees, therotated constellation exactly overlaps with its original one. This“rotation-sense” symmetric property makes the capacities and the averagepowers of the real and imaginary components equal to each other. BothNUQs and NUCs are defined specifically for each code rate and theparticular one used is signaled by the parameter DP_MOD filed in thePLS2 data.

The time interleaver 5050 may operates at a DP level. Parameters of timeinterleaving (TI) may be set differently for each DP. A detailedoperation of the time interleaver 5050 will be described later.

A processing block 5000-1 of the BICM block to which MIMO is applied mayinclude the data FEC encoder, the bit interleaver, the constellationmapper, and the time interleaver.

However, the processing block 5000-1 is distinguished from theprocessing block 5000 of the BICM block to which MIMO is not applied inthat the processing block 5000-1 further includes a cell-worddemultiplexer 5010-1 and a MIMO encoding block 5020-1.

In addition, operations of the data FEC encoder, the bit interleaver,the constellation mapper, and the time interleaver in the processingblock 5000-1 correspond to those of the data FEC encoder 5010, the bitinterleaver 5020, the constellation mapper 5030, and the timeinterleaver 5050 described above, and thus description thereof isomitted.

The cell-word demultiplexer 5010-1 is used for a DP of the advancedprofile to divide a single cell-word stream into dual cell-word streamsfor MIMO processing.

The MIMO encoding block 5020-1 may process an output of the cell-worddemultiplexer 5010-1 using a MIMO encoding scheme. The MIMO encodingscheme is optimized for broadcast signal transmission. MIMO technologyis a promising way to obtain a capacity increase but depends on channelcharacteristics. Especially for broadcasting, a strong LOS component ofa channel or a difference in received signal power between two antennascaused by different signal propagation characteristics makes itdifficult to obtain capacity gain from MIMO. The proposed MIMO encodingscheme overcomes this problem using rotation-based precoding and phaserandomization of one of MIMO output signals.

MIMO encoding is intended for a 2×2 MIMO system requiring at least twoantennas at both the transmitter and the receiver. A MIMO encoding modeof the present invention may be defined as full-rate spatialmultiplexing (FR-SM). FR-SM encoding may provide capacity increase withrelatively small complexity increase at the receiver side. In addition,the MIMO encoding scheme of the present invention has no restriction onan antenna polarity configuration.

MIMO processing is applied at the DP level. NUQ (e_(1,i) and e_(2,i))corresponding to a pair of constellation mapper outputs is fed to aninput of a MIMO encoder. Paired MIMO encoder output (g1,i and g2,i) istransmitted by the same carrier k and OFDM symbol 1 of respective TXantennas thereof.

The above-described blocks may be omitted or replaced by blocks havingsimilar or identical functions.

FIG. 20 illustrates a BICM block according to another embodiment of thepresent invention.

The BICM block illustrated in FIG. 20 corresponds to another embodimentof the BICM block 1010 described with reference to FIG. 18.

FIG. 20 illustrates a BICM block for protection of physical layersignaling (PLS), an emergency alert channel (EAC) and a fast informationchannel (FIC). The EAC is a part of a frame that carries EAS informationdata, and the FIC is a logical channel in a frame that carries mappinginformation between a service and a corresponding base DP. Details ofthe EAC and FIC will be described later.

Referring to FIG. 20, the BICM block for protection of the PLS, the EACand the FIC may include a PLS FEC encoder 6000, a bit interleaver 6010and a constellation mapper 6020.

In addition, the PLS FEC encoder 6000 may include a scrambler, a BCHencoding/zero insertion block, an LDPC encoding block and an LDPC paritypuncturing block. Description will be given of each block of the BICMblock.

The PLS FEC encoder 6000 may encode scrambled PLS 1/2 data, EAC and FICsections.

The scrambler may scramble PLS1 data and PLS2 data before BCH encodingand shortened and punctured LDPC encoding.

The BCH encoding/zero insertion block may perform outer encoding on thescrambled PLS 1/2 data using a shortened BCH code for PLS protection,and insert zero bits after BCH encoding. For PLS1 data only, output bitsof zero insertion may be permutted before LDPC encoding.

The LDPC encoding block may encode an output of the BCH encoding/zeroinsertion block using an LDPC code. To generate a complete coded block,C_(ldpc) and parity bits P_(ldpc) are encoded systematically from eachzero-inserted PLS information block I_(ldpc) and appended thereto.

C _(ldpc) =[I _(ldpc) P _(ldpc) ]=[i ₀ , i ₁ , . . . , i _(K) _(ldpc) ⁻¹, p ₀ , p ₁ , . . . , p _(N) _(ldpc) _(−K) _(ldpc) ⁻¹]  [Equation 1]

The LDPC parity puncturing block may perform puncturing on the PLS1 dataand the PLS2 data.

When shortening is applied to PLS1 data protection, some LDPC paritybits are punctured after LDPC encoding. In addition, for PLS2 dataprotection, LDPC parity bits of PLS2 are punctured after LDPC encoding.These punctured bits are not transmitted.

The bit interleaver 6010 may interleave each of shortened and puncturedPLS1 data and PLS2 data.

The constellation mapper 6020 may map the bit-ineterleaved PLS1 data andPLS2 data to constellations.

The above-described blocks may be omitted or replaced by blocks havingsimilar or identical functions.

FIG. 21 illustrates a bit interleaving process of PLS according to anembodiment of the present invention.

Each shortened and punctured PLS1 and PLS2 coded block is interleavedbit-by-bit as described in FIG. 22. Each block of additional parity bitsis interleaved with the same block interleaving structure butseparately.

In the case of BPSK, there are two branches for bit interleaving toduplicate FEC coded bits in the real and imaginary parts. Each codedblock is written to the upper branch first. The bits are mapped to thelower branch by applying modulo N_(FEC) addition with cyclic shiftingvalue floor(N_(FEC)/2), where N_(FEC) is the length of each LDPC codedblock after shortening and puncturing.

In other modulation cases, such as QSPK, QAM-16 and NUQ-64, FEC codedbits are written serially into the interleaver column-wise, where thenumber of columns is the same as the modulation order.

In the read operation, the bits for one constellation symbol are readout sequentially row-wise and fed into the bit demultiplexer block.These operations are continued until the end of the column.

Each bit interleaved group is demultiplexed bit-by-bit in a group beforeconstellation mapping. Depending on modulation order, there are twomapping rules. In the case of BPSK and QPSK, the reliability of bits ina symbol is equal. Therefore, the bit group read out from the bitinterleaving block is mapped to a QAM symbol without any operation.

In the cases of QAM-16 and NUQ-64 mapped to a QAM symbol, the rule ofoperation is described in FIG. 23(a). As shown in FIG. 23(a), i is bitgroup index corresponding to column index in bit interleaving.

FIG. 21 shows the bit demultiplexing rule for QAM-16. This operationcontinues until all bit groups are read from the bit interleaving block.

FIG. 22 illustrates a configuration of a broadcast signal receptionapparatus for future broadcast services according to an embodiment ofthe present invention.

The broadcast signal reception apparatus for future broadcast servicesaccording to the embodiment of the present invention may correspond tothe broadcast signal transmission apparatus for future broadcastservices described with reference to FIG. 18.

The broadcast signal reception apparatus for future broadcast servicesaccording to the embodiment of the present invention may include asynchronization & demodulation module 9000, a frame parsing module 9010,a demapping & decoding module 9020, an output processor 9030 and asignaling decoding module 9040. A description will be given of operationof each module of the broadcast signal reception apparatus.

The synchronization & demodulation module 9000 may receive input signalsthrough m Rx antennas, perform signal detection and synchronization withrespect to a system corresponding to the broadcast signal receptionapparatus, and carry out demodulation corresponding to a reverseprocedure of a procedure performed by the broadcast signal transmissionapparatus.

The frame parsing module 9010 may parse input signal frames and extractdata through which a service selected by a user is transmitted. If thebroadcast signal transmission apparatus performs interleaving, the frameparsing module 9010 may carry out deinterleaving corresponding to areverse procedure of interleaving. In this case, positions of a signaland data that need to be extracted may be obtained by decoding dataoutput from the signaling decoding module 9040 to restore schedulinginformation generated by the broadcast signal transmission apparatus.

The demapping & decoding module 9020 may convert input signals into bitdomain data and then deinterleave the same as necessary. The demapping &decoding module 9020 may perform demapping of mapping applied fortransmission efficiency and correct an error generated on a transmissionchannel through decoding. In this case, the demapping & decoding module9020 may obtain transmission parameters necessary for demapping anddecoding by decoding data output from the signaling decoding module9040.

The output processor 9030 may perform reverse procedures of variouscompression/signal processing procedures which are applied by thebroadcast signal transmission apparatus to improve transmissionefficiency. In this case, the output processor 9030 may acquirenecessary control information from data output from the signalingdecoding module 9040. An output of the output processor 9030 correspondsto a signal input to the broadcast signal transmission apparatus and maybe MPEG-TSs, IP streams (v4 or v6 ) and generic streams.

The signaling decoding module 9040 may obtain PLS information from asignal demodulated by the synchronization & demodulation module 9000. Asdescribed above, the frame parsing module 9010, the demapping & decodingmodule 9020 and the output processor 9030 may execute functions thereofusing data output from the signaling decoding module 9040.

A frame according to an embodiment of the present invention is furtherdivided into a number of OFDM symbols and a preamble. As shown in (d),the frame includes a preamble, one or more frame signaling symbols(FSSs), normal data symbols and a frame edge symbol (FES).

The preamble is a special symbol that enables fast futurecast UTB systemsignal detection and provides a set of basic transmission parameters forefficient transmission and reception of a signal. Details of thepreamble will be described later.

A main purpose of the FSS is to carry PLS data. For fast synchronizationand channel estimation, and hence fast decoding of PLS data, the FSS hasa dense pilot pattern than a normal data symbol. The FES has exactly thesame pilots as the FSS, which enables frequency-only interpolationwithin the FES and temporal interpolation, without extrapolation, forsymbols immediately preceding the FES.

FIG. 23 illustrates a signaling hierarchy structure of a frame accordingto an embodiment of the present invention.

FIG. 23 illustrates the signaling hierarchy structure, which is splitinto three main parts corresponding to preamble signaling data 11000,PLS1 data 11010 and PLS2 data 11020. A purpose of a preamble, which iscarried by a preamble symbol in every frame, is to indicate atransmission type and basic transmission parameters of the frame. PLS1enables the receiver to access and decode the PLS2 data, which containsthe parameters to access a DP of interest. PLS2 is carried in everyframe and split into two main parts corresponding to PLS2-STAT data andPLS2-DYN data. Static and dynamic portions of PLS2 data are followed bypadding, if necessary.

Preamble signaling data according to an embodiment of the presentinvention carries 21 bits of information that are needed to enable thereceiver to access PLS data and trace DPs within the frame structure.Details of the preamble signaling data are as follows.

FFT_SIZE: This 2-bit field indicates an FFT size of a current framewithin a frame group as described in the following Table 1.

TABLE 1 Value FFT size 00  8K FFT 01 16K FFT 10 32K FFT 11 Reserved

GI_FRACTION: This 3-bit field indicates a guard interval fraction valuein a current superframe as described in the following Table 2.

TABLE 2 Value GI_FRACTION 000 ⅕ 001 1/10 010 1/20 011 1/40 100 1/80 1011/160 110 to 111 Reserved

EAC_FLAG: This 1-bit field indicates whether the EAC is provided in acurrent frame. If this field is set to ‘1’, an emergency alert service(EAS) is provided in the current frame. If this field set to ‘0’, theEAS is not carried in the current frame. This field may be switcheddynamically within a superframe.

PILOT_MODE: This 1-bit field indicates whether a pilot mode is a mobilemode or a fixed mode for a current frame in a current frame group. Ifthis field is set to ‘0’, the mobile pilot mode is used. If the field isset to ‘1’, the fixed pilot mode is used.

PAPR_FLAG: This 1-bit field indicates whether PAPR reduction is used fora current frame in a current frame group. If this field is set to avalue of ‘1’, tone reservation is used for PAPR reduction. If this fieldis set to a value of ‘0’, PAPR reduction is not used.

RESERVED: This 7-bit field is reserved for future use.

FIG. 24 illustrates PLS1 data according to an embodiment of the presentinvention.

PLS1 data provides basic transmission parameters including parametersrequired to enable reception and decoding of PLS2. As mentioned above,the PLS1 data remain unchanged for the entire duration of one framegroup. A detailed definition of the signaling fields of the PLS1 data isas follows.

PREAMBLE_DATA: This 20-bit field is a copy of preamble signaling dataexcluding EAC_FLAG.

NUM_FRAME_FRU: This 2-bit field indicates the number of the frames perFRU.

PAYLOAD_TYPE: This 3-bit field indicates a format of payload datacarried in a frame group. PAYLOAD_TYPE is signaled as shown in Table 3.

TABLE 3 Value Payload type 1XX TS is transmitted. X1X IP stream istransmitted. XX1 GS is transmitted.

NUM_FSS: This 2-bit field indicates the number of FSSs in a currentframe.

SYSTEM_VERSION: This 8-bit field indicates a version of a transmittedsignal format. SYSTEM_VERSION is divided into two 4-bit fields: a majorversion and a minor version.

Major version: The MSB corresponding to four bits of the SYSTEM_VERSIONfield indicates major version information. A change in the major versionfield indicates a non-backward-compatible change. A default value is‘0000’. For a version described in this standard, a value is set to‘0000’.

Minor version: The LSB corresponding to four bits of SYSTEM_VERSIONfield indicates minor version information. A change in the minor versionfield is backwards compatible.

CELL_ID: This is a 16-bit field which uniquely identifies a geographiccell in an ATSC network. An ATSC cell coverage area may include one ormore frequencies depending on the number of frequencies used perfuturecast UTB system. If a value of CELL_ID is not known orunspecified, this field is set to ‘0’.

NETWORK_ID: This is a 16-bit field which uniquely identifies a currentATSC network.

SYSTEM_ID: This 16-bit field uniquely identifies the futurecast UTBsystem within the ATSC network. The futurecast UTB system is aterrestrial broadcast system whose input is one or more input streams(TS, IP, GS) and whose output is an RF signal. The futurecast UTB systemcarries one or more PHY profiles and FEF, if any. The same futurecastUTB system may carry different input streams and use different RFs indifferent geographical areas, allowing local service insertion. Theframe structure and scheduling are controlled in one place and areidentical for all transmissions within the futurecast UTB system. One ormore futurecast UTB systems may have the same SYSTEM_ID meaning thatthey all have the same physical layer structure and configuration.

The following loop includes FRU_PHY_PROFILE, FRU_FRAME_LENGTH,FRU_GI_FRACTION, and RESERVED which are used to indicate an FRUconfiguration and a length of each frame type. A loop size is fixed sothat four PHY profiles (including an FEF) are signaled within the FRU.If NUM_FRAME_FRU is less than 4, unused fields are filled with zeros.

FRU_PHY_PROFILE: This 3-bit field indicates a PHY profile type of an(i+1)^(th) (i is a loop index) frame of an associated FRU. This fielduses the same signaling format as shown in Table 8.

FRU_FRAME_LENGTH: This 2-bit field indicates a length of an (i+1)^(th)frame of an associated FRU. Using FRU_FRAME_LENGTH together withFRU_GI_4FRACTION, an exact value of a frame duration may be obtained.

FRU_GI_FRACTION: This 3-bit field indicates a guard interval fractionvalue of an (i+1)^(th) frame of an associated FRU. FRU_GI_FRACTION issignaled according to Table 7.

RESERVED: This 4-bit field is reserved for future use.

The following fields provide parameters for decoding the PLS2 data.

PLS2 FEC TYPE: This 2-bit field indicates an FEC type used by PLS2protection. The FEC type is signaled according to Table 4. Details ofLDPC codes will be described later.

TABLE 4 Content PLS2 FEC type 00 4K-1/4 and 7K-3/10 LDPC codes 01 to 11Reserved

PLS2_MOD: This 3-bit field indicates a modulation type used by PLS2. Themodulation type is signaled according to Table 5.

TABLE 5 Value PLS2_MODE 000 BPSK 001 QPSK 010 QAM-16 011 NUQ-64 100 to111 Reserved

PLS2_SIZE_CELL: This 15-bit field indicates C_(total_partial_block), asize (specified as the number of QAM cells) of the collection of fullcoded blocks for PLS2 that is carried in a current frame group. Thisvalue is constant during the entire duration of the current frame group.

PLS2_STAT_SIZE_BIT: This 14-bit field indicates a size, in bits, ofPLS2-STAT for a current frame group. This value is constant during theentire duration of the current frame group.

PLS2_DYN_SIZE_BIT: This 14-bit field indicates a size, in bits, ofPLS2-DYN for a current frame group. This value is constant during theentire duration of the current frame group.

PLS2_REP_FLAG: This 1-bit flag indicates whether a PLS2 repetition modeis used in a current frame group. When this field is set to a value of‘1’, the PLS2 repetition mode is activated. When this field is set to avalue of ‘0’, the PLS2 repetition mode is deactivated.

PLS2_REP_SIZE_CELL: This 15-bit field indicates C_(total_partial_block),a size (specified as the number of QAM cells) of the collection ofpartial coded blocks for PLS2 carried in every frame of a current framegroup, when PLS2 repetition is used. If repetition is not used, a valueof this field is equal to 0. This value is constant during the entireduration of the current frame group.

PLS2_NEXT_FEC_TYPE: This 2-bit field indicates an FEC type used for PLS2that is carried in every frame of a next frame group. The FEC type issignaled according to Table 10.

PLS2_NEXT_MOD: This 3-bit field indicates a modulation type used forPLS2 that is carried in every frame of a next frame group. Themodulation type is signaled according to Table 11.

PLS2_NEXT_REP_FLAG: This 1-bit flag indicates whether the PLS2repetition mode is used in a next frame group. When this field is set toa value of ‘1’, the PLS2 repetition mode is activated. When this fieldis set to a value of ‘0’, the PLS2 repetition mode is deactivated.

PLS2_NEXT_REP_SIZE_CELL: This 15-bit field indicatesC_(total_full_block), a size (specified as the number of QAM cells) ofthe collection of full coded blocks for PLS2 that is carried in everyframe of a next frame group, when PLS2 repetition is used. If repetitionis not used in the next frame group, a value of this field is equal to0. This value is constant during the entire duration of a current framegroup.

PLS2_NEXT_REP_STAT_SIZE_BIT: This 14-bit field indicates a size, inbits, of PLS2-STAT for a next frame group. This value is constant in acurrent frame group.

PLS2_NEXT_REP_DYN_SIZE_BIT: This 14-bit field indicates the size, inbits, of the PLS2-DYN for a next frame group. This value is constant ina current frame group.

PLS2_AP_MODE: This 2-bit field indicates whether additional parity isprovided for PLS2 in a current frame group. This value is constantduring the entire duration of the current frame group. Table 6 belowprovides values of this field. When this field is set to a value of‘00’, additional parity is not used for the PLS2 in the current framegroup.

TABLE 6 Value PLS2-AP mode 00 AP is not provided 01 AP1 mode 10 to 11Reserved

PLS2_AP_SIZE_CELL: This 15-bit field indicates a size (specified as thenumber of QAM cells) of additional parity bits of PLS2. This value isconstant during the entire duration of a current frame group.

PLS2_NEXT_AP_MODE: This 2-bit field indicates whether additional parityis provided for PLS2 signaling in every frame of a next frame group.This value is constant during the entire duration of a current framegroup. Table 12 defines values of this field.

PLS2_NEXT_AP_SIZE_CELL: This 15-bit field indicates a size (specified asthe number of QAM cells) of additional parity bits of PLS2 in everyframe of a next frame group. This value is constant during the entireduration of a current frame group.

RESERVED: This 32-bit field is reserved for future use.

CRC_32: A 32-bit error detection code, which is applied to all PLS1signaling.

FIG. 25 illustrates PLS2 data according to an embodiment of the presentinvention.

FIG. 25 illustrates PLS2-STAT data of the PLS2 data. The PLS2-STAT datais the same within a frame group, while PLS2-DYN data providesinformation that is specific for a current frame.

Details of fields of the PLS2-STAT data are described below.

FIC_FLAG: This 1-bit field indicates whether the FIC is used in acurrent frame group. If this field is set to ‘1’, the FIC is provided inthe current frame. If this field set to ‘0’, the FIC is not carried inthe current frame. This value is constant during the entire duration ofa current frame group.

AUX_FLAG: This 1-bit field indicates whether an auxiliary stream is usedin a current frame group. If this field is set to ‘1’, the auxiliarystream is provided in a current frame. If this field set to ‘0’, theauxiliary stream is not carried in the current frame. This value isconstant during the entire duration of current frame group.

NUM_DP: This 6-bit field indicates the number of DPs carried within acurrent frame. A value of this field ranges from 1 to 64, and the numberof DPs is NUM_DP+1.

DP_ID: This 6-bit field identifies uniquely a DP within a PHY profile.

DP_TYPE: This 3-bit field indicates a type of a DP. This is signaledaccording to the following Table 7.

TABLE 7 Value DP Type 000 DP Type 1 001 DP Type 2 010 to 111 Reserved

DP_GROUP_ID: This 8-bit field identifies a DP group with which a currentDP is associated. This may be used by the receiver to access DPs ofservice components associated with a particular service having the sameDP_GROUP_ID.

BASE_DP_ID: This 6-bit field indicates a DP carrying service signalingdata (such as PSI/SI) used in a management layer. The DP indicated byBASE_DP_ID may be either a normal DP carrying the service signaling dataalong with service data or a dedicated DP carrying only the servicesignaling data.

DP_FEC_TYPE: This 2-bit field indicates an FEC type used by anassociated DP. The FEC type is signaled according to the following Table8.

TABLE 8 Value FEC_TYPE 00 16K LDPC 01 64K LDPC 10 to 11 Reserved

DP_COD: This 4-bit field indicates a code rate used by an associated DP.The code rate is signaled according to the following Table 9.

TABLE 9 Value Code rate 0000  5/15 0001  6/15 0010  7/15 0011  8/15 0100 9/15 0101 10/15 0110 11/15 0111 12/15 1000 13/15 1001 to 1111 Reserved

DP_MOD: This 4-bit field indicates modulation used by an associated DP.The modulation is signaled according to the following Table 10.

TABLE 10 Value Modulation 0000 QPSK 0001 QAM-16 0010 NUQ-64 0011 NUQ-2560100 NUQ-1024 0101 NUC-16 0110 NUC-64 0111 NUC-256 1000 NUC-1024 1001 to1111 Reserved

DP_SSDP_FLAG: This 1-bit field indicates whether an SSD mode is used inan associated DP. If this field is set to a value of ‘1’, SSD is used.If this field is set to a value of ‘0’, SSD is not used.

The following field appears only if PHY_PROFILE is equal to ‘010’, whichindicates the advanced profile:

DP_MIMO: This 3-bit field indicates which type of MIMO encoding processis applied to an associated DP. A type of MIMO encoding process issignaled according to the following Table 11.

TABLE 11 Value MIMO encoding 000 FR-SM 001 FRFD-SM 010 to 111 Reserved

DP_TI_TYPE: This 1-bit field indicates a type of time interleaving. Avalue of ‘0’ indicates that one TI group corresponds to one frame andcontains one or more TI blocks. A value of ‘1’ indicates that one TIgroup is carried in more than one frame and contains only one TI block.

DP_TI_LENGTH: The use of this 2-bit field (allowed values are only 1, 2,4, and 8) is determined by values set within the DP_TI_TYPE field asfollows.

If DP_TI_TYPE is set to a value of ‘1’, this field indicates P_(I), thenumber of frames to which each TI group is mapped, and one TI block ispresent per TI group (N_(TI)=1). Allowed values of P_(i) with the 2-bitfield are defined in Table 12 below.

If DP_TI_TYPE is set to a value of ‘0’, this field indicates the numberof TI blocks N_(TI) per TI group, and one TI group is present per frame(P_(I)=1). Allowed values of P_(I) with the 2-bit field are defined inthe following Table 12.

TABLE 12 2-bit field P_(I) N_(TI) 00 1 1 01 2 2 10 4 3 11 8 4

DP_FRAME_INTERVAL: This 2-bit field indicates a frame interval(I_(JUMP)) within a frame group for an associated DP and allowed valuesare 1, 2, 4, and 8 (the corresponding 2-bit field is ‘00’, ‘01’, ‘10’,or ‘11’, respectively). For DPs that do not appear every frame of theframe group, a value of this field is equal to an interval betweensuccessive frames. For example, if a DP appears on frames 1, 5, 9, 13,etc., this field is set to a value of ‘4’. For DPs that appear in everyframe, this field is set to a value of ‘1’.

DP_TI_BYPASS: This 1-bit field determines availability of the timeinterleaver 5050. If time interleaving is not used for a DP, a value ofthis field is set to ‘1’. If time interleaving is used, the value is setto ‘0’.

DP_FIRST_FRAME_IDX: This 5-bit field indicates an index of a first frameof a superframe in which a current DP occurs. A value ofDP_FIRST_FRAME_IDX ranges from 0 to 31.

DP_NUM_BLOCK_MAX: This 10-bit field indicates a maximum value ofDP_NUM_BLOCKS for this DP. A value of this field has the same range asDP_NUM_BLOCKS.

DP_PAYLOAD_TYPE: This 2-bit field indicates a type of payload datacarried by a given DP. DP_PAYLOAD_TYPE is signaled according to thefollowing Table 13.

TABLE 13 Value Payload type 00 TS 01 IP 10 GS 11 Reserved

DP_INBAND_MODE: This 2-bit field indicates whether a current DP carriesin-band signaling information. An in-band signaling type is signaledaccording to the following Table 14.

TABLE 14 Value In-band mode 00 In-band signaling is not carried. 01INBAND-PLS is carried 10 INBAND-ISSY is carried 11 INBAND-PLS andINBAND-ISSY are carried

DP_PROTOCOL_TYPE: This 2-bit field indicates a protocol type of apayload carried by a given DP. The protocol type is signaled accordingto Table 15 below when input payload types are selected.

TABLE 15 If If If DP_PAYLOAD_TYPE DP_PAYLOAD_TYPE DP_PAYLOAD_TYPE Valueis TS is IP is GS 00 MPEG2-TS IPv4 (Note) 01 Reserved IPv6 Reserved 10Reserved Reserved Reserved 11 Reserved Reserved Reserved

DP_CRC_MODE: This 2-bit field indicates whether CRC encoding is used inan input formatting block. A CRC mode is signaled according to thefollowing Table 16.

TABLE 16 Value CRC mode 00 Not used 01 CRC-8 10 CRC-16 11 CRC-32

DNP_MODE: This 2-bit field indicates a null-packet deletion mode used byan associated DP when DP_PAYLOAD_TYPE is set to TS (‘00’). DNP MODE issignaled according to Table 17 below. If DP_PAYLOAD_TYPE is not TS(‘00’), DNP_MODE is set to a value of ‘00’.

TABLE 17 Value Null-packet deletion mode 00 Not used 01 DNP-NORMAL 10DNP-OFFSET 11 Reserved

ISSY_MODE: This 2-bit field indicates an ISSY mode used by an associatedDP when DP_PAYLOAD_TYPE is set to TS (‘00’). ISSY_MODE is signaledaccording to Table 18 below. If DP_PAYLOAD_TYPE is not TS (‘00’),ISSY_MODE is set to the value of ‘00’.

TABLE 18 Value ISSY mode 00 Not used 01 ISSY-UP 10 ISSY-BBF 11 Reserved

HC_MODE_TS: This 2-bit field indicates a TS header compression mode usedby an associated DP when DP_PAYLOAD_TYPE is set to TS (‘00’). HC_MODE_TSis signaled according to the following Table 19.

TABLE 19 Value Header compression mode 00 HC_MODE_TS 1 01 HC_MODE_TS 210 HC_MODE_TS 3 11 HC_MODE_TS 4

HC_MODE_IP: This 2-bit field indicates an IP header compression modewhen DP_PAYLOAD_TYPE is set to IP (‘01’). HC MODE IP is signaledaccording to the following Table 20.

TABLE 20 Value Header compression mode 00 No compression 01 HC_MODE_IP 110 to 11 Reserved

PID: This 13-bit field indicates the PID number for TS headercompression when DP_PAYLOAD_TYPE is set to TS (‘00’) and HC_MODE_TS isset to ‘01’ or ‘10’.

RESERVED: This 8-bit field is reserved for future use.

The following fields appear only if FIC_FLAG is equal to ‘1’.

FIC_VERSION: This 8-bit field indicates the version number of the FIC.

FIC_LENGTH_BYTE: This 13-bit field indicates the length, in bytes, ofthe FIC.

RESERVED: This 8-bit field is reserved for future use.

The following fields appear only if AUX_FLAG is equal to ‘1’.

NUM_AUX: This 4-bit field indicates the number of auxiliary streams.Zero means no auxiliary stream is used.

AUX_CONFIG_RFU: This 8-bit field is reserved for future use.

AUX_STREAM_TYPE: This 4-bit is reserved for future use for indicating atype of a current auxiliary stream.

AUX PRIVATE CONFIG: This 28-bit field is reserved for future use forsignaling auxiliary streams.

FIG. 26 illustrates PLS2 data according to another embodiment of thepresent invention.

FIG. 26 illustrates PLS2-DYN data of the PLS2 data. Values of thePLS2-DYN data may change during the duration of one frame group whilesizes of fields remain constant.

Details of fields of the PLS2-DYN data are as below.

FRAME_INDEX: This 5-bit field indicates a frame index of a current framewithin a superframe. An index of a first frame of the superframe is setto ‘0’.

PLS_CHANGE_COUNTER: This 4-bit field indicates the number of superframesbefore a configuration changes. A next superframe with changes in theconfiguration is indicated by a value signaled within this field. Ifthis field is set to a value of ‘0000’, it means that no scheduledchange is foreseen. For example, a value of ‘1’ indicates that there isa change in the next superframe.

FIC_CHANGE_COUNTER: This 4-bit field indicates the number of superframesbefore a configuration (i.e., content of the FIC) changes. A nextsuperframe with changes in the configuration is indicated by a valuesignaled within this field. If this field is set to a value of ‘0000’,it means that no scheduled change is foreseen. For example, a value of‘0001’ indicates that there is a change in the next superframe.

RESERVED: This 16-bit field is reserved for future use.

The following fields appear in a loop over NUM DP, which describeparameters associated with a DP carried in a current frame.

DP_ID: This 6-bit field uniquely indicates a DP within a PHY profile.

DP_START: This 15-bit (or 13-bit) field indicates a start position ofthe first of the DPs using a DPU addressing scheme. The DP_START fieldhas differing length according to the PHY profile and FFT size as shownin the following Table 21.

TABLE 21 DP_START field size PHY profile 64K 16K Base 13 bits 15 bitsHandheld — 13 bits Advanced 13 bits 15 its 

DP_NUM_BLOCK: This 10-bit field indicates the number of FEC blocks in acurrent TI group for a current DP. A value of DP_NUM_BLOCK ranges from 0to 1023.

RESERVED: This 8-bit field is reserved for future use.

The following fields indicate FIC parameters associated with the EAC.

EAC_FLAG: This 1-bit field indicates the presence of the EAC in acurrent frame. This bit is the same value as EAC_FLAG in a preamble.

EAS_WAKE_UP_VERSION_NUM: This 8-bit field indicates a version number ofa wake-up indication.

If the EAC_FLAG field is equal to ‘1’, the following 12 bits areallocated to EAC_LENGTH_BYTE. If the EAC_FLAG field is equal to ‘0’, thefollowing 12 bits are allocated to EAC_COUNTER.

EAC_LENGTH_BYTE: This 12-bit field indicates a length, in bytes, of theEAC.

EAC_COUNTER: This 12-bit field indicates the number of frames before aframe where the EAC arrives.

The following fields appear only if the AUX_FLAG field is equal to ‘1’.

AUX_PRIVATE_DYN: This 48-bit field is reserved for future use forsignaling auxiliary streams. A meaning of this field depends on a valueof AUX_STREAM_TYPE in a configurable PLS2-STAT.

CRC_32: A 32-bit error detection code, which is applied to the entirePLS2.

FIG. 27 illustrates a logical structure of a frame according to anembodiment of the present invention.

As above mentioned, the PLS, EAC, FIC, DPs, auxiliary streams and dummycells are mapped to the active carriers of OFDM symbols in a frame. PLS1and PLS2 are first mapped to one or more FSSs. Thereafter, EAC cells, ifany, are mapped to an immediately following PLS field, followed next byFIC cells, if any. The DPs are mapped next after the PLS or after theEAC or the FIC, if any. Type 1 DPs are mapped first and Type 2 DPs aremapped next. Details of types of the DPs will be described later. Insome cases, DPs may carry some special data for EAS or service signalingdata. The auxiliary streams or streams, if any, follow the DPs, which inturn are followed by dummy cells. When the PLS, EAC, FIC, DPs, auxiliarystreams and dummy data cells are mapped all together in the abovementioned order, i.e. the PLS, EAC, FIC, DPs, auxiliary streams anddummy data cells, cell capacity in the frame is exactly filled.

FIG. 28 illustrates PLS mapping according to an embodiment of thepresent invention.

PLS cells are mapped to active carriers of FSS(s). Depending on thenumber of cells occupied by PLS, one or more symbols are designated asFSS(s), and the number of FSS(s) NFSS is signaled by NUM_FSS in PLS1.The FSS is a special symbol for carrying PLS cells. Since robustness andlatency are critical issues in the PLS, the FSS(s) have higher pilotdensity, allowing fast synchronization and frequency-only interpolationwithin the FSS.

PLS cells are mapped to active carriers of the FSS(s) in a top-downmanner as shown in the figure. PLS1 cells are mapped first from a firstcell of a first FSS in increasing order of cell index. PLS2 cells followimmediately after a last cell of PLS1 and mapping continues downwarduntil a last cell index of the first FSS. If the total number ofrequired PLS cells exceeds the number of active carriers of one FSS,mapping proceeds to a next FSS and continues in exactly the same manneras the first FSS.

After PLS mapping is completed, DPs are carried next. If an EAC, an FICor both are present in a current frame, the EAC and the FIC are placedbetween the PLS and “normal” DPs.

Hereinafter, description will be given of encoding an FEC structureaccording to an embodiment of the present invention. As above mentioned,the data FEC encoder may perform FEC encoding on an input BBF togenerate an FECBLOCK procedure using outer coding (BCH), and innercoding (LDPC). The illustrated FEC structure corresponds to theFECBLOCK. In addition, the FECBLOCK and the FEC structure have samevalue corresponding to a length of an LDPC codeword.

As described above, BCH encoding is applied to each BBF (K_(bc)h bits),and then LDPC encoding is applied to BCH-encoded BBF (K_(ldpc)bits=N_(bch) bits).

A value of N_(ldpc) is either 64,800 bits (long FECBLOCK) or 16,200 bits(short FECBLOCK).

Table 22 and Table 23 below show FEC encoding parameters for the longFECBLOCK and the short FECBLOCK, respectively.

TABLE 22 BCH error LDPC correction rate N_(ldpc) K_(ldpc) K_(bch)capability N_(bch)-K_(bch) 5/15 64800 21600 21408 12 192 6/15 2592025728 7/15 30240 30048 8/15 34560 34368 9/15 38880 38688 10/15  4320043008 11/15  47520 47328 12/15  51840 51648 13/15  56160 55968

TABLE 23 BCH error LDPC correction rate N_(ldpc) K_(ldpc) K_(bch)capability N_(bch)-K_(bch) 5/15 16200 5400 5232 12 168 6/15 6480 63127/15 7560 7392 8/15 8640 8472 9/15 9720 9552 10/15  10800 10632 11/15 11880 11712 12/15  12960 12792 13/15  14040 13872

Detailed operations of BCH encoding and LDPC encoding are as below.

A 12-error correcting BCH code is used for outer encoding of the BBF. ABCH generator polynomial for the short FECBLOCK and the long FECBLOCKare obtained by multiplying all polynomials together.

LDPC code is used to encode an output of outer BCH encoding. To generatea completed B_(ldpc) (FECBLOCK), P_(ldpc) (parity bits) is encodedsystematically from each I_(ldpc) (BCH—encoded BBF), and appended toI_(ldpc). The completed B_(ldpc) (FECBLOCK) is expressed by thefollowing Equation.

B _(ldpc) =[I _(ldpc) P _(ldpc) ]=[i ₀ , i ₁ , . . . , i _(K) _(ldpc) ⁻¹, p ₁ , p ₁ , . . . , p _(N) _(ldpc) _(−k) _(ldpc) ⁻¹]  [Equation 2]

Parameters for the long FECBLOCK and the short FECBLOCK are given in theabove Tables 22 and 23, respectively.

A detailed procedure to calculate N_(ldpc)−K_(ldpc) parity bits for thelong FECBLOCK, is as follows.

1) Initialize the parity bits

p₀=p₁=p₂= . . . p_(N) _(ldpc) _(−K) _(ldpc) ⁻¹=0   [Equation 3]

2) Accumulate a first information bit-i₀, at a parity bit addressspecified in a first row of addresses of a parity check matrix. Detailsof the addresses of the parity check matrix will be described later. Forexample, for the rate of 13/15,

p₉₈₃=p₉₈₃ ⊕ i₀ p₂₈₁₅=p₂₈₁₅ ⊕ i₀

p₄₈₃₇=p₄₈₃₇ ⊕ i₀ p₄₉₈₉=p₄₉₈₉ ⊕ i₀

p₆₁₃₈=p₆₁₃₈ ⊕ i₀ p₆₄₅₈=p₆₄₅₈ ⊕ i₀

p₆₉₂₁=p₆₉₂₁ ⊕ i₀ p₆₉₇₄=p₆₉₇₄ ⊕ i₀

p₇₅₇₂=p₇₅₇₂ ⊕ i₀ p₈₂₆₀=p₈₂₆₀ ⊕ i₀

p₈₄₉₆=p₈₄₉₆ ⊕₀   [Equation 4]

3) For the next 359 information bits, i_(s), s=1, 2, . . . , 359,accumulate i_(s) at parity bit addresses using following Equation.

{x+(s mod 360)×Q_(ldpc)} mod (N_(ldpc)−K_(ldpc))   [Equation 5]

Here, x denotes an address of a parity bit accumulator corresponding toa first bit i₀, and Q_(ldpc) is a code rate dependent constant specifiedin the addresses of the parity check matrix. Continuing with theexample, Q_(ldpc)=24 for the rate of 13/15, so for an information biti₁, the following operations are performed.

p₁₀₀₇=p₁₀₀₇ ⊕ i₁ p₂₈₃₉=p₂₈₃₉ ⊕ i₁

p₄₈₆₁=p₄₈₆₁ ⊕ i₁ p₅₀₁₃=p₅₀₁₃ ⊕ i₁

p₆₁₆₂=p₆₁₆₂ ⊕ i₁ p₆₄₈₇=p₆₄₈₂ ⊕ i₁

p₆₉₄₅=p₆₉₄₅ ⊕ i₁ p₆₉₉₈=p₆₉₉₈ ⊕ i₁

p₇₅₉₆=p₇₅₉₆ ⊕ i₁ p₈₂₈₄=p₈₂₈₄ ⊕ i₁

₈₅₂₀=p₈₅₂₀ ⊕ i₁   [Equation 6]

4) For a 361th information bit i₃₆₀, an address of the parity bitaccumulator is given in a second row of the addresses of the paritycheck matrix. In a similar manner, addresses of the parity bitaccumulator for the following 359 information bits i_(s), s=361, 362, .. . , 719 are obtained using Equation 6, where x denotes an address ofthe parity bit accumulator corresponding to the information bit i₃₆₀,i.e., an entry in the second row of the addresses of the parity checkmatrix.

5) In a similar manner, for every group of 360 new information bits, anew row from the addresses of the parity check matrix is used to findthe address of the parity bit accumulator.

After all of the information bits are exhausted, a final parity bit isobtained as below.

6) Sequentially perform the following operations starting with i=1.

p _(i) =p _(i) ⊕ p _(i−1) , i=1, 2 . . . , N _(ldpc) −K _(ldpc)−1  [Equation 7]

Here, final content of p_(i) (i=0, 1, . . . , N_(ldpc)−K_(ldpc)−1) isequal to a parity bit p_(i).

TABLE 24 Code rate Q_(ldpc) 5/15 120 6/15 108 7/15 96 8/15 84 9/15 7210/15  60 11/15  48 12/15  36 13/15  24

This LDPC encoding procedure for the short FECBLOCK is in accordancewith t LDPC encoding procedure for the long FECBLOCK, except that Table24 is replaced with Table 25, and the addresses of the parity checkmatrix for the long FECBLOCK are replaced with the addresses of theparity check matrix for the short FECBLOCK.

TABLE 25 Code rate Q_(ldpc) 5/15 30 6/15 27 7/15 24 8/15 21 9/15 1810/15  15 11/15  12 12/15  9 13/15  6

FIG. 29 illustrates time interleaving according to an embodiment of thepresent invention.

(a) to (c) show examples of a TI mode.

A time interleaver operates at the DP level. Parameters of timeinterleaving (TI) may be set differently for each DP.

The following parameters, which appear in part of the PLS2-STAT data,configure the TI.

DP_TI_TYPE (allowed values: 0 or 1): This parameter represents the TImode. The value of ‘0’ indicates a mode with multiple TI blocks (morethan one TI block) per TI group. In this case, one TI group is directlymapped to one frame (no inter-frame interleaving). The value of ‘1’indicates a mode with only one TI block per TI group. In this case, theTI block may be spread over more than one frame (inter-frameinterleaving).

DP_TI_LENGTH: If DP_TI_TYPE=‘0’, this parameter is the number of TIblocks N_(TI) per TI group. For DP_TI_TYPE=‘1’, this parameter is thenumber of frames P_(I) spread from one TI group.

DP_NUM_BLOCK_MAX (allowed values: 0 to 1023): This parameter representsthe maximum number of XFECBLOCKs per TI group.

DP_RAME_INTERVAL (allowed values: 1, 2, 4, and 8): This parameterrepresents the number of the frames hump between two successive framescarrying the same DP of a given PHY profile.

DP_TI_BYPASS (allowed values: 0 or 1): If time interleaving is not usedfor a DP, this parameter is set to ‘1’. This parameter is set to ‘0’ iftime interleaving is used.

Additionally, the parameter DP_NUM_BLOCK from the PLS2-DYN data is usedto represent the number of XFECBLOCKs carried by one TI group of the DP.

When time interleaving is not used for a DP, the following TI group,time interleaving operation, and TI mode are not considered. However,the delay compensation block for the dynamic configuration informationfrom the scheduler may still be required. In each DP, the XFECBLOCKsreceived from SSD/MIMO encoding are grouped into TI groups. That is,each TI group is a set of an integer number of XFECBLOCKs and contains adynamically variable number of XFECBLOCKs. The number of XFECBLOCKs inthe TI group of index n is denoted by N_(xBLOCK_Group)(n) and issignaled as DP_NUM_BLOCK in the PLS2-DYN data. Note thatN_(xBLOCK_Group)(n) may vary from a minimum value of 0 to a maximumvalue of N_(xBLOCK_Group_MAX) (corresponding to DP_NUM_BLOCK_MAX), thelargest value of which is 1023.

Each TI group is either mapped directly to one frame or spread overP_(I) frames. Each TI group is also divided into more than one TI block(N_(TI)), where each TI block corresponds to one usage of a timeinterleaver memory. The TI blocks within the TI group may containslightly different numbers of XFECBLOCKs. If the TI group is dividedinto multiple TI blocks, the TI group is directly mapped to only oneframe. There are three options for time interleaving (except an extraoption of skipping time interleaving) as shown in the following Table26.

TABLE 26 Modes Descriptions Option 1 Each TI group contains one TI blockand is mapped directly to one frame as shown in (a). This option issignaled in PLS2- STAT by DP_TI_TYPE = ‘0’ and DP_TI_LENGTH = ‘1’(N_(TI) = 1). Option 2 Each TI group contains one TI block and is mappedto more than one frame. (b) shows an example, where one TI group ismapped to two frames, i.e., DP_TI_LENGTH = ‘2’ (P_(I) = 2) andDP_FRAME_INTERVAL (I_(JUMP) = 2). This provides greater time diversityfor low data-rate services. This option is signaled in PLS2-STAT byDP_TI_TYPE = ‘1’. Option 3 Each TI group is divided into multiple TIblocks and is mapped directly to one frame as shown in (c). Each TIblock may use a full TI memory so as to provide a maximum bit-rate for aDP. This option is signaled in PLS2-STAT by DP_TI_TYPE = ‘0’ andDP_TI_LENGTH = N_(TI), while P_(I) = 1.

Typically, the time interleaver may also function as a buffer for DPdata prior to a process of frame building. This is achieved by means oftwo memory banks for each DP. A first TI block is written to a firstbank. A second TI block is written to a second bank while the first bankis being read from and so on.

The TI is a twisted row-column block interleaver. For an s^(th) TI blockof an n^(th) TI group, the number of rows N_(r) of a TI memory is equalto the number of cells N_(cells), i.e., N_(r)=N_(cells) while the numberof columns N_(c) is equal to the number N_(xBLOCK_TI)(n,s).

FIG. 30 illustrates a basic operation of a twisted row-column blockinterleaver according to an embodiment of the present invention.

FIG. 30(a) shows a write operation in the time interleaver and FIG.30(b) shows a read operation in the time interleaver. A first XFECBLOCKis written column-wise into a first column of a TI memory, and a secondXFECBLOCK is written into a next column, and so on as shown in (a).Then, in an interleaving array, cells are read diagonal-wise. Duringdiagonal-wise reading from a first row (rightwards along a row beginningwith a left-most column) to a last row, N_(r) cells are read out asshown in (b). In detail, assuming z_(n,s,i)(i=0, . . . , N_(r)N_(c)) asa TI memory cell position to be read sequentially, a reading process insuch an interleaving array is performed by calculating a row indexR_(n,s,i), a column index C_(n,s,i), and an associated twistingparameter T_(n,s,i) as in the following Equation.

$\begin{matrix}{{{GENERATE}\left( {R_{n,s,i},C_{n,s,i}} \right)} = \left\{ {{R_{n,s,i} = {{mod}\left( {i,N_{r}} \right)}},{T_{n,s,i} = {{mod}\left( {{S_{shift} \times R_{n,s,i}},N_{c}} \right)}},{C_{n,s,i} = {{mod}\left( {{T_{n,s,i} + \left\lfloor \frac{i}{N_{r}} \right\rfloor},N_{c}} \right)}}} \right\}} & \left\lbrack {{Equation}\mspace{20mu} 8} \right\rbrack\end{matrix}$

Here, S_(shift) is a common shift value for a diagonal-wise readingprocess regardless of N_(xBLOCK_TI) (n,s), and the shift value isdetermined by N_(xBLOCK_TI_MAX) given in PLS2-STAT as in the followingEquation.

$\begin{matrix}{{for}\left\{ {\begin{matrix}\begin{matrix}{N_{{xBLOCK\_ TI}{\_ MAX}}^{\prime} =} \\{{N_{{xBLOCK\_ TI}{\_ MAX}} + 1},}\end{matrix} & {{{if}\mspace{14mu} N_{{xBLOCK\_ TI}{\_ MAX}}{{mod}2}} = 0} \\\begin{matrix}{N_{{xBLOCK\_ TI}{\_ MAX}}^{\prime} =} \\{N_{{xBLOCK\_ TI}{\_ MAX}},}\end{matrix} & {{{if}\mspace{14mu} N_{{xBLOCK\_ TI}{\_ MAX}}{{mod}2}} = 1}\end{matrix},{S_{shift} = \frac{N_{{xBLOCK\_ TI}{\_ MAX}}^{\prime} - 1}{2}}} \right.} & \left\lbrack {{Equation}\mspace{14mu} 9} \right\rbrack\end{matrix}$

As a result, cell positions to be read are calculated by coordinatesz_(n,s,i)=N_(r)C_(n,s,i)+R_(n,s,i).

FIG. 31 illustrates an operation of a twisted row-column blockinterleaver according to another embodiment of the present invention.

More specifically, FIG. 31 illustrates an interleaving array in a TImemory for each TI group, including virtual XFECBLOCKs whenN_(xBLOCK-TI)(0,0)=3, N_(xBLOCK_TI)(1,0)=6, and N_(xBLOCK_TI)(2,0)=.5

A variable number N_(xBLOCK_TI)(n,s)=N_(r) may be less than or equal toN_(xBLOCK_TI_MAX). Thus, in order to achieve single-memorydeinterleaving at a receiver side regardless of N_(xBLOCK_TI)(n,s), theinterleaving array for use in the twisted row-column block interleaveris set to a size of N_(r)×N_(c)=N_(cells)×N′_(xBLOCK_TI_MAX) byinserting the virtual XFECBLOCKs into the TI memory and a readingprocess is accomplished as in the following Equation.

[Equation 10]   p = 0; for i = 0;i < N_(cells)N_(xBLOCK)_TI_MAX′;i =i+1{GENERATE (R_(n,s,i),C_(n,s,i)); V_(i) = N_(r)C_(n,s,j), + R_(n,s,j)  ifV_(i) < N_(cells)N_(xBLOCK)_TI(n,s)  {   Z_(n,s,p) = V_(i); p = p+1;   }}

The number of TI groups is set to 3. An option of the time interleaveris signaled in the PLS2-STAT data by DP_TI_TYPE=‘0’,DP_FRAME_INTERVAL=‘1’, and DP_TI_LENGTH=‘1’, i.e., NTI=1, IJUMP=1, andPI=1. The number of XFECBLOCKs, each of which has Ncells=30 cells, perTI group is signaled in the PLS2-DYN data by NxBLOCK_TI(0,0)=3,NxBLOCK_TI(1,0)=6, and NxBLOCK_TI(2,0)=5, respectively. A maximum numberof XFECBLOCKs is signaled in the PLS2-STAT data by NxBLOCK_Group_MAX,which leads to └N_(xBLOCK_Group_MAX)/N_(TI)┘=N_(xBLOCK_TI_MAX)=6.

The purpose of the Frequency Interleaver, which operates on datacorresponding to a single OFDM symbol, is to provide frequency diversityby randomly interleaving data cells received from the frame builder. Inorder to get maximum interleaving gain in a single frame, a differentinterleaving-sequence is used for every OFDM symbol pair comprised oftwo sequential OFDM symbols.

Therefore, the frequency interleaver according to the present embodimentmay include an interleaving address generator for generating aninterleaving address for applying corresponding data to a symbol pair.

FIG. 32 illustrates an interleaving address generator including a mainpseudo-random binary sequence (PRBS) generator and a sub-PRBS generatoraccording to each FFT mode according to an embodiment of the presentinvention.

(a) shows the block diagrams of the interleaving-address generator for8K FFT mode, (b) shows the block diagrams of the interleaving-addressgenerator for 16K FFT mode and (c) shows the block diagrams of theinterleaving-address generator for 32K FFT mode.

The interleaving process for the OFDM symbol pair is described asfollows, exploiting a single interleaving-sequence. First, availabledata cells (the output cells from the Cell Mapper) to be interleaved inone OFDM symbol O_(m,l) is defined as O_(m,l)=[x_(m,l,0), . . . ,x_(m,l,p), . . . , x_(m,l,N) _(data) ⁻¹] for l=0, . . . , N_(sym)−1,where x_(m,l,p) is the p^(th) cell of the l^(th) OFDM symbol in them^(th) frame and N_(data) is the number of data cells: N_(data)=C_(FSS)for the frame signaling symbol(s), N_(data)=C_(data) for the normaldata, and N_(data)=C_(FES) for the frame edge symbol. In addition, theinterleaved data cells are defined as p_(m,l)=[v_(m,l,0), . . . ,v_(m,l,N) _(data) ⁻¹] for l=0, . . . , N_(sym)−1.

For the OFDM symbol pair, the interleaved OFDM symbol pair is given byv_(m,l,H) _(i) _((p))=x_(m,l,p), p=0, . . . , N_(data)−1, for the firstOFDM symbol of each pair v_(m,l,p)=x_(m,l,H) _(l_hd (p)) , p=0, . . . ,N_(data)−1, for the second OFDM symbol of each pair, where H_(l)(p) isthe interleaving

address generated by a PRBS generator.

FIG. 33 illustrates a main PRBS used for all FFT modes according to anembodiment of the present invention.

(a) illustrates the main PRBS, and (b) illustrates a parameter Nmax foreach FFT mode.

FIG. 34 illustrates a sub-PRBS used for FFT modes and an interleavingaddress for frequency interleaving according to an embodiment of thepresent invention.

(a) illustrates a sub-PRBS generator, and (b) illustrates aninterleaving address for frequency interleaving. A cyclic shift valueaccording to an embodiment of the present invention may be referred toas a symbol offset.

FIG. 35 illustrates a write operation of a time interleaver according toan embodiment of the present invention.

FIG. 35 illustrates a write operation for two TI groups.

A left block in the figure illustrates a TI memory address array, andright blocks in the figure illustrate a write operation when two virtualFEC blocks and one virtual FEC block are inserted into heads of twocontiguous TI groups, respectively.

Hereinafter, description will be given of a configuration of a timeinterleaver and a time interleaving method using both a convolutionalinterleaver (CI) and a block interleaver (BI) or selectively usingeither the CI or the BI according to a physical layer pipe (PLP) mode. APLP according to an embodiment of the present invention is a physicalpath corresponding to the same concept as that of the above-describedDP, and a name of the PLP may be changed by a designer.

A PLP mode according to an embodiment of the present invention mayinclude a single PLP mode or a multi-PLP mode according to the number ofPLPs processed by a broadcast signal transmitter or a broadcast signaltransmission apparatus. The single PLP mode corresponds to a case inwhich one PLP is processed by the broadcast signal transmissionapparatus. The single PLP mode may be referred to as a single PLP.

The multi-PLP mode corresponds to a case in which one or more PLPs areprocessed by the broadcast signal transmission apparatus. The multi-PLPmode may be referred to as multiple PLPs.

In the present invention, time interleaving in which different timeinterleaving schemes are applied according to PLP modes may be referredto as hybrid time interleaving. Hybrid time interleaving according to anembodiment of the present invention is applied for each PLP (or at eachPLP level) in the multi-PLP mode.

FIG. 36 illustrates an interleaving type applied according to the numberof PLPs in a table.

In a time interleaving according to an embodiment of the presentinvention, an interleaving type may be determined based on a value ofPLP_NUM. PLP_NUM is a signaling field indicating a PLP mode. WhenPLP_NUM has a value of 1, the PLP mode corresponds to a single PLP. Thesingle PLP according to the present embodiment may be applied only to aCI.

When PLP_NUM has a value greater than 1, the PLP mode corresponds tomultiple PLPs. The multiple PLPs according to the present embodiment maybe applied to the CI and a BI. In this case, the CI may performinter-frame interleaving, and the BI may perform intra-frameinterleaving.

FIG. 37 is a block diagram including a first example of a structure of ahybrid time interleaver described above.

The hybrid time interleaver according to the first example may include aBI and a CI. The time interleaver of the present invention may bepositioned between a BICM chain block and a frame builder.

The BICM chain block illustrated in FIGS. 37 and 38 may include theblocks in the processing block 5000 of the BICM block illustrated inFIG. 19 except for the time interleaver 5050. The frame builderillustrated in FIGS. 37 and 38 may perform the same function as that ofthe frame building block 1020 of FIG. 18.

As described in the foregoing, it is possible to determine whether toapply the BI according to the first example of the structure of thehybrid time interleaver depending on values of PLP_NUM. That is, whenPLP_NUM=1, the BI is not applied (BI is turned OFF) and only the CI isapplied. When PLP_NUM>1, both the BI and the CI may be applied (BI isturned ON). A structure and an operation of the CI applied whenPLP_NUM>1 may be the same as or similar to a structure and an operationof the CI applied when PLP_NUM=1.

FIG. 38 is a block diagram including a second example of the structureof the hybrid time interleaver described above.

An operation of each block included in the second example of thestructure of the hybrid time interleaver is the same as the abovedescription in FIG. 20. It is possible to determine whether to apply aBI according to the second example of the structure of the hybrid timeinterleaver depending on values of PLP_NUM. Each block of the hybridtime interleaver according to the second example may perform operationsaccording to embodiments of the present invention. In this instance, anapplied structure and operation of a CI may be different between a caseof PLP_NUM=1 and a case of PLP_NUM>1.

FIG. 39 is a block diagram including a first example of a structure of ahybrid time deinterleaver.

The hybrid time deinterleaver according to the first example may performan operation corresponding to a reverse operation of the hybrid timeinterleaver according to the first example described above. Therefore,the hybrid time deinterleaver according to the first example of FIG. 39may include a convolutional deinterleaver (CDI) and a blockdeinterleaver (BDI).

A structure and an operation of the CDI applied when PLP_NUM>1 may bethe same as or similar to a structure and an operation of the CDIapplied when PLP_NUM=1.

It is possible to determine whether to apply the BDI according to thefirst example of the structure of the hybrid time deinterleaverdepending on values of PLP_NUM. That is, when PLP_NUM=1, the BDI is notapplied (BDI is turned OFF) and only the CDI is applied.

The CDI of the hybrid time deinterleaver may perform inter-framedeinterleaving, and the BDEI may perform intra-frame deinterleaving.Details of inter-frame deinterleaving and intra-frame deinterleaving arethe same as the above description.

A BICM decoding block illustrated in FIGS. 39 and 40 may perform areverse operation of the BICM chain block of FIGS. 37 and 38.

FIG. 40 is a block diagram including a second example of the structureof the hybrid time deinterleaver.

The hybrid time deinterleaver according to the second example mayperform an operation corresponding to a reverse operation of the hybridtime interleaver according to the second example described above. Anoperation of each block included in the second example of the structureof the hybrid time deinterleaver may be the same as the abovedescription in FIG. 39.

It is possible to determine whether to apply a BDI according to thesecond example of the structure of the hybrid time deinterleaverdepending on values of PLP_NUM. Each block of the hybrid timedeinterleaver according to the second example may perform operationsaccording to embodiments of the present invention. In this instance, anapplied structure and operation of a CDI may be different between a caseof PLP_NUM=1 and a case of PLP_NUM>1.

FIG. 41 is a block diagram of an electronic device according to anembodiment of the present invention.

Referring to FIG. 41, the electronic device 100 includes a controller110 and a communication unit 120. The controller 110 may establish acommunication linkage with a companion device. In addition, when thecommunication linkage with the companion device is established, thecommunication unit 120 may exchange data with the companion device.

In addition, the controller 110 may include a network processor 111 andan application processor 112. The application processor 112 may requestconnection with the companion device from the network processor 111.

The network processor 111 may place the connection request received fromthe application processor 112 in a standby state since the networkprocessor 111 has not been connected with the companion device.Thereafter, the network processor 111 may receive a connection requestfrom the companion device. The network processor 111 may search for amatching connection request from the application processor 112 based oninformation received from the companion device. Upon finding thematching connection request, the network processor 111 may connect thecompanion device to the application processor 112.

As an example, the application processor 112 may correspond to anapplication module or an application browser. Alternatively, theapplication processor 112 may correspond to an HbbTV application. As anexample, the network processor 111 may be implemented as a networkmodule. Alternatively, the network processor 111 may correspond to aWebSocket server. The network processor 111 may interconnect theapplication processor 112 and the companion device. As an example, whenthe network processor 111 is implemented as the WebSocket server, eachof the application processor 112 and the companion device may beregarded as one client. In other words, the WebSocket server may connecta first client and a second client. Alternatively, each of the firstclient and the second client may be referred to as a peer. Depending oncases, the WebSocket server may be implemented as a separate deviceoutside the electronic device.

Meanwhile, the application processor 112 may operate one application. Inaddition, the companion device may operate one application. Theapplication processor 112 may be connected to the companion devicethrough the network processor 111. The companion device may receive datafrom the application processor 112 and receive and drive an applicationwhich is being driven by the application processor 112. Alternatively,each of the application processor 112 and the companion device may drivean application. The application processor 112 may be connected to thecompanion device to exchange data with the companion device. In thiscase, the electronic device 100 and the companion device may beconsidered to perform inter-application communication.

The WebSocket server may be used as a repeater and may generate acommunication channel between applications. The generated communicationchannel may enable the electronic device 100 and the companion device tocommunicate with each other. The WebSocket server may connect a channelbetween applications requesting the same information using a name ID andan origin ID of an application desiring to perform communication togenerate a communication channel. For example, the above-describedmethod may connect an application (client) and an application (client)without correcting a WebSocket API in HbbTV 2.0.

In this specification, respective terms are interchangeable.

FIG. 42 is a diagram for description of connection of a first clientaccording to an embodiment of the present invention.

FIG. 42 illustrates an electronic device 100 a and a companion device200 a. The electronic device 100 a may include an application processorand a network processor. As an example, the application processor maycorrespond to an HbbTV application or a first application, and thenetwork processor may correspond to an HbbTV WebSocket server. Thecompanion device 200 a may include a companion device processor. As anexample, the companion device processor may correspond to a companionapplication or a second client. The WebSocket server may need to bechanged to connect the clients. Hereinafter, an operation related tochange of the WebSocket server will be described. The changed WebSocketserver may be driven in HbbTV 2.0 TV.

Usually, a WebSocket client specifies the remote host to which it wishesto establish a connection, and the relative URI for the desired serviceon that host in the initial GET request along with the WebSocketconnection upgrade header. In HbbTV, however, it cannot be assumed that,the peer with which communications are to be established, has contactedthe WebSocket server yet. A connection request from a client in thespecial client-to-client mode, hence needs to be kept active untilanother, suitable peer arrives.

To achieve this, we define special uses for two fields of the WebSocketprotocol upgrade GET request. The Request-URI—which is part of theRequest-Line—takes a predefined format with a common prefix string. Thisfield is used to match corresponding communication peers. The Hostrequest-header field may either refer to the TV set running theWebSocket server (in which case communications with any peer with amatching Request-URI will be established), or to a specific companiondevice (in which case communications only with the designated device,and with a matching Request-URI will be established).

The format for the Request-URI field may be according to the followingABNF grammar:

HbbTV-Request-URI=“/hbbtv/” org-id “.” app-id

org-id=8HEX

app-id=4HEX

In response to such a request, an HbbTV WebSocket server may create astream head, that is a half open connection, which is associated withthe Request-URI supplied in the upgrade GET request by the client. Theserver may not respond immediately with a WebSocket Protocol Handshakeresponse, but instead wait for other peers to appear, and thereby keepthe first client waiting. If the server wishes to implement a time-out,it may respond with a 504 Gateway Timeout response.

Clients may not use the Sec-WebSocket-Protocol header when requestingclient-to-client connections. Servers may ignore theSec-WebSocket-Protocol header in requests for client-to-clientconnections. Servers may respond with a 403 Forbidden response if theHost header field in a client-to-client connection request does notspecify a device on any of the local sub-networks that the server isattached to. All HbbTV 2.0 WebSocket clients may use the methoddescribed in this section to request client-to-client connections fromHbbTV 2.0 WebSocket servers.

FIG. 43 is a diagram for description of connection of a second clientaccording to an embodiment of the present invention.

FIG. 43 illustrates an electronic device 100a and a companion device 200a. The electronic device 100 a may include an application processor anda network processor. The network processor (for example, a WebSocketserver) may receive a connection request from an HbbTV application and acompanion application.

When another client requests a client-to-client connection using themethod as above, the server may also create a stream head for that newrequest as shown in FIG. 3. After a new stream head is created, theserver may search the collection of stream heads currently waiting to beconnected, for Request-URI and Host header field values matching thoseof the newly created stream head. If no match is found, the server mayadd the newly created stream head to the collection of stream headscurrently waiting to be connected, and may keep waiting for furtherclient-to-client connection requests.

FIG. 44 is a diagram for description of connection between the first andsecond clients according to an embodiment of the present invention.

FIG. 44 illustrates an electronic device 100 a and a companion device200 a. The electronic device 100 a may include an application processorand a network processor. The network processor (for example, a WebSocketserver) may connect an HbbTV application and a companion application.

If a newly created stream head is associated with the same Request-URIand Host header field values as a stream head in the collection ofstream heads currently waiting to be connected, the server may removethe matching stream head from the collection, and may establish afull-duplex communications channel between the two stream heads.

Once the two stream heads are connected, the server outputs all datareceived from one stream head immediately and without alteration to therespective other stream head. Thereby, a transparent communicationschannel is established between the two clients.

If one of the two clients sends a Close frame, the server may send acorresponding Close frame to the other client. If one of the two clientsdisconnects without sending a Close frame, the server may generate aClose frame, and may send the same to the other client.

In other words, the network processor may generate a stream head of theapplication processor and include the stream head in a stream head groupin response to a connection request from the application processor. Inaddition, in response to a connection request from the companion device,the network processor may generate a stream head of the companion deviceand verify whether a matching stream head is present. When the matchingstream head is present, the network processor may connect a stream headof the application processor and a stream head of the companion devicematching from the stream head group. In this instance, the networkprocessor may remove the matching stream head of the applicationprocessor or the matching stream head of the companion device from thestream head group.

FIG. 45 is a diagram for description of an additional connection requestaccording to an embodiment of the present invention.

Referring to FIG. 45, an HbbTV application (client) is connected to acompanion application (client) of a companion device 200 a. In addition,the HbbTV application may generate another stream head for anotherclient. The HbbTV application may be additionally connected to anotherapplication. Any stream head be removed from the collection of streamheads available for connecting, prior to establishing a client-to-clientconnection, such client-to-client connections are one-to-one only. If aclient wishes to communicate with more than one other client, it mayissue further connection requests to the server until the maximum numberof client-to-client connections it is able to process, has been reached.

WebSocket servers may not allow more than one stream head for the sameclient with the same Request-URI and Host to be on the collection ofstream heads currently waiting to be connected. If a client issuesanother client-to-client connection request with the same Request-URIand Host, before the previous one has been successfully connected or hastimed-out, the server may respond with a 403 Forbidden response.

Clients may have several client-to-client connection requests withdifferent Request-URI/Host combinations in the waiting to be connectedstate. Clients may not attempt to request another client-to-clientconnection with the same Request-URI/Host combination, before theprevious one was either successfully connected or has timed-out.

An “/hbbtv/orgid.appid scheme” for the Request-URI may be used as anescape into the special server client-to-client behavior in order toallow it to be implemented along with other, standard WebSocket serverfunctionalities, and without interfering with the same. The choice ofmatching the Request-URI and Host header field allows for twoapproaches: if a specific device is targeted by the Host header, theclient only wishes to talk to that specific other client. It may havelearnt about its existence through other means (e.g. SSDP as part ofUPnP). Secondly, if the Host header field targets the server, it will bethe same for all clients targeting the same server. This will result inonly the Request-URI being the discriminating factor for choosingsuitable communication peers. Hence, targeting the server in the Hostheader field effectively provides a wildcard match with any other clientusing the same Request-URI and also targeting the server. As such, bothdedicated and opportunistic connection establishment strategies arepossible.

Since the HbbTV 2.0 WebSocket server does not perform anyauthentication, authorization, or other verification, no trust can beassociated with client-to-client connections, or between clients andWebSocket servers. Clients that wish to exchange private, or otherwisesensitive information through a WebSocket server should therefore employend-to-end encryption to ensure the privacy of the communication.Likewise, such clients should employ cryptographic methods to establishthe identity and authenticity of any communication peers with which theywish to communicate through a WebSocket server. Since an HbbTV 2.0WebSocket server will establish connections only to clients who haveindicated the intent of being connected, it is very unlikely that asuccessful denial-of-service attack could be staged against anotherclient through an HbbTV WebSocket server. The client under attack cansimply stop asking the server to be connected to other clients.

Since it is defined that a server may reject simultaneous connectionattempts to a not yet connected Request-URI/Host combination, adenial-of-service attack might be attempted against the server itself.This could be done by repeatedly sending the same connection request toprovoke error responses, or by sending random connection requests in anattempt to exhaust the server's resources by creating many open streamheads. Both techniques are general strategies for attacking HTTPservers, and are not specific to WebSocket or HbbTV. It is henceexpected that any WebSocket server implementation (be it of the HbbTVflavor or not) will have suitable mitigation mechanisms (e.g. bystopping sending responses or creating stream heads).

FIG. 46 is a diagram for description of connection between clients whenan IP address is not present according to an embodiment of the presentinvention.

FIG. 46 illustrates a method of establishing a communication linkagebetween clients. The above-described inter-application communicationmethod based on WebSocket may enable a WebSocket server to connectapplications, URI paths (paths excluding a host name) of which are thesame, to perform inter-application communication. Inter-clientcommunication may divide an application driven in an electronic device(for example, a TV application) and an application driven in a companiondevice (for example, a CS application), thereby selectively performinginter-application communication.

As an example, in HbbTV, a Request-URI may be configured withoutincluding an IP address. A URI path may start with a reserved word(“hbbtv”) indicating HbbTV after a root (“/”), and may include anorganization or company ID (org-id) and an application ID (app-id)thereafter. The WebSocket server (network processor) may connectapplications, WebSocket API call URI paths of which are the same.

Syntax) GET “/hbbtv/”org-id“.”app-id

Example) GET/hbbtv/org.mychannel.myapp

Meanwhile, respective clients requesting connection may use the sameport or different ports. When the clients use the same port, theWebSocket server may recognize that a called application is an HbbTVapplication if IPs of applications calling a WebSocket API are the same,and may recognize that a called application is a companion deviceapplication if the IPs are different from each other. When the same portis used, the WebSocket server may simplify server implementation andtest, and discovery is unnecessary. (With most WebSocket libraries, needto start a different instance per port. Single port drasticallysimplifies server implementation and test. No discovery needed ifapp-2-app server listens on well-defined port on the TV.)

Next, a description will be given of a case in which the clients usedifferent ports. This case refers to a case in which an applicationdriven by a TV and an application driven by a companion device use thesame URI path and use different ports. As an embodiment, an HbbTVapplication driven by the TV may use port 8900, and an applicationdriven by the companion device may use port 8901. When the WebSocketserver knows ports used by a TV application and a companion application,it is possible to distinguish between communication between the TVapplication and the companion application and inter-companionapplication communication. When different ports are used, if severalcompanion devices are connected to a TV using the same hostrequest-header, clients may be easily connected by distinguishing thecompanion devices and the TV. Since the TV and the companion devicescommunicate with each other by being connected to the WebSocket serverthrough different ports while host request-headers are the same, it ispossible to distinguish between the companion device and the TV.Therefore, it is possible to take complementary measures in terms ofsecurity.

FIG. 47 is a diagram for description of standby connection forconnection between applications according to an embodiment of thepresent invention.

FIG. 47 illustrates an electronic device 100 a and a companion device200 a. A TV application of the electronic device 100 a may transmit aconnection request to a WebSocket server. The TV application is includedin the electronic device, and thus the WebSocket server may recognizethe TV application as a local application. In addition, a companionapplication is present outside the electronic device, and thus theWebSocket server may recognize the companion application as a remoteapplication. As an embodiment, an application may use methods below whenrequesting connection.

TABLE 27 String getApp2AppLocalBaseURL ( ) Description Returns the baseURL of the application to application communication service localend-point. Arguments No arguments

TABLE 28 String getApp2AppRemoteBaseURL ( ) Description Returns the baseURL of the application to application communication service remoteend-point. Arguments No arguments

As an embodiment, a network processor may execute W3C WebSocket API, andmay support a minimum of 200 simultaneous WebSocket connections.

The network processor may provide two service end points executed by aserver side of a WebSocket protocol specification. A local end point isused for connection to the network processor by an HbbTV application. Aremote end point may be connected to a home network by an application ofanother device, and is used to include a remote companion application oran HbbTV application driven by another HbbTV device. The HbbTVapplication may be connected to a local service end point of a networkprocessor in which the application operates or a remote service endpoint of another hybrid terminal in the same home network. It ispreferable that the network processor not be connected to a localservice end point of another device in the home network. For example,this can be achieved by placing a local service end point of a localloopback interface of the network processor. When another service endpoint executes the service side of the WebSocket protocol specification,and the HbbTV application or the companion application uses the serviceend point, the hybrid terminal should not place the service end point onthe same host and port combination as another service end point.

A basic URL for a service end point between applications may be aWebSocket URL. The WebSocket URL may define a host, a port, security,and a resource name of a service end point. A client needs to beconnected to a host and a port specified by the WebSocket URL of theservice end point. A resource name used in an initial protocol requestby the client conforms to ABNF grammar.

resource-name=base-url-resource-name app-endpoint

Base-url-resource-name is a resource name derived from a WebSocket URLof a service end point. App-endpoint is an application specification andmay be used for a client connection matching process corresponding tothe client. A message of the corresponding client may be deliveredthrough a WebSocket protocol. App-endpoint may be selected by anapplication developer to avoid collision. Therefore, app-endpoint maystart with an ID formatted in reverse DNS notation uniquely related tothe HbbTV application, the companion application, or a developerthereof. The hybrid terminal may support app-endpoint including acertain character permitted in a resource name by a minimum length of1000 characters and the WebSocket protocol specification.

A service end point may support a minimum of ten simultaneous TCP socketconnections from a client. When the client attempts to open connectionbetween a server and a TCP socket, the server may reject a request ifthe server cannot manage simultaneous connection. Otherwise, the servermay approve TCP socket connection, and start WebSocket protocolhandshake. When the server receives a request handshake from the client,the server may not immediately respond with a handshake response.Instead, the server may wait until connection is paired or connection ofthe client is canceled. In this state, standby connection may beconfigured as connection. When the server attempts to execute time-out,the server may respond with a 504 gateway time-out response.

The server may ignore a certain origin header of a request handshaketransmitted by the client. The client may not use aSec-WebSocket-protocol header when requesting connection betweenclients. The server may ignore the Sec-WebSocket-protocol header in arequest for connection between clients. The server may not approve arequest from the client for protocol extension using theSec-WebSocket-protocol header. When the client uses a Sec-WebSocketextension header, the server may not establish a connection using ascheme defined in the WebSocket protocol specification.

As illustrated in FIG. 47, an HbbTV application operating as a clientmay attempt connection with a local service end point which hasapp-endpoint of “org.mychannel.myapp” and base-url-resource-name of/hbbtv/. Connection with the companion device may be maintained in astandby state since the companion application has not been linked tocommunication between applications using the same app-endpoint.

FIG. 48 is a diagram for description of a new connection request forconnection with a second client according to an embodiment of thepresent invention.

Referring to FIG. 48, an HbbTV application (client) is connected to acompanion application (client) of a companion device 200 a. In addition,the HbbTV application may generate another stream head for anotherclient.

A server cannot permit one or more simultaneous standby connections fromthe same original IP address having the same app-endpoint. Whensuccessfully connected or when a client of an IP address prior totermination issues another connection request using the sameapp-endpoint, the server may respond with a 403 Forbidden response.

A client may desire establishment of connection between multiplesimultaneous clients through the same service end points using differentresource-name combinations. The client cannot attempt to request anotherconnection from an existing service end point before standby to connectthe service end point is successful or time-out or connection iscanceled. This operation of the client may be defined by a WebSocketprotocol specification.

According to FIG. 48, when a client desires to communicate with one ormore clients, the client may wait until existing standby connection ispaired. In this instance, an additional connection request may be issuedto the server until a maximum number of processable inter-clientconnections is reached. In other words, the HbbTV application maygenerate a new standby connection request to permit establishment ofinter-application communication.

Meanwhile, the client may include an IP address in a URI path.

FIG. 49 is a diagram for description of setting of a first client whenan IP address is included according to an embodiment of the presentinvention.

As an embodiment, the above-described URI path starts with a reservedword (“hbbtb”) indicating HbbTV after a root (“/”), and may include anorganization/company ID (org-id) and an application ID (app-id)thereafter. An application desiring to perform inter-applicationcommunication may add an IP address of a driven device to a URI path todesignate a target application. A WebSocket server may connectapplications, WebSocket API call URI paths of which are the same,according to IP to be used for communication.

Syntax) GET “/hbbtv/” target IP “/” org-id “.” app-id

Example) GET /hbbtv/1.1.1.1/org.mychannel.myapp

As an embodiment, a TV application A may be driven in IP 1.1.1.1, acompanion application B may be driven in IP 1.1.1.2 (a first userterminal), and a companion application C may be driven in IP 1.1.1.3 (asecond user terminal). In this instance, the TV application A mayattempt to communicate with the companion application C. The TVapplication A may include IP (1.1.1.3) in which the companionapplication C is driven in a URI path which is included in a WebSocketrequest. In addition, the companion application C may include IP(1.1.1.1) of the TV application A in a URI path which is included in aWebSocket request.

According to FIG. 49, a URI path may correspond tohbbtv/192.0.2.7/org.mychannel.myapp HTTP/1/1. Here, 192.0.2.7 maycorrespond to an IP address of a target application. 192.0.2.110 maycorrespond to an IP address thereof. In addition, org.mychannel.myappmay correspond to an application ID.

FIG. 50 is a diagram for description of setting of a first client and asecond client when IP addresses are included according to an embodimentof the present invention.

A WebSocket server may receive the URI request described with referenceto FIG. 49 from each of the clients. Referring to FIG. 50, the firstclient has an IP address of 192.0.2.110, and the second client has an IPaddress of 192.0.2.7. When the first client requests connection from thesecond client, a start point (From Host) is 192.0.2.110, and adestination (To Host) is 192.0.2.7. In addition, an application ID maybe org.mychannel.myapp. When the second client requests connection fromthe first client, a start point (From Host) is 192.0.2.7, and adestination (To Host) is 192.0.2.110. In addition, an application ID maybe org.mychannel.myapp. That is, start points and destinations of thefirst client and the second client may be opposite to each other.However, application IDs may be the same. The WebSocket server mayconnect matching clients to each other.

In addition, a URI path including a host IP address may be used.

For example, the URI path may be used as below. Syntax) GET “/”hbbtv“/”host_address“/”org-id “.” app-id,

Example) GET /hbbtv/192.0.2.7/org.mychannel.myapp.

FIG. 51 is a diagram for description of an embodiment of connection to aplurality of second clients when IP addresses are included.

Referring to FIG. 51, an HbbTV has a certain IP address and includes anapplication ID of org.mychannel.myapp. A first companion application IPaddress is 192.0.2.7, and a second companion application IP address is192.0.2.1. Application IDs of first and second companion applicationscorrespond to org.mychannel.myapp. As described above with reference toFIG. 50, the WebSocket server may connect matching clients to eachother. Therefore, the WebSocket server may connect matching clients toeach other in response to requests from respective clients.

In this way, when an IP address is used in a URI path, both clientsdesignate an object to be connected. Thus, security is improved, clientsmay be connected to each other, and all information may be matchedwithout extra effort. Meanwhile, even when an IP address is used in aURI path, respective clients may use the same port or may use differentports.

FIG. 52 is a flowchart of a method of controlling an electronic deviceaccording to an embodiment of the present invention.

Referring to FIG. 52, in S1210, the electronic device is connected to acompanion device. The electronic device may include a network processorand an application processor. In the electronic device, the applicationprocessor may request connection to a companion device from the networkprocessor. Upon receiving a connection request from the companiondevice, the network processor may connect the application processorrequesting connection to the companion device.

As described in the foregoing, the application processor may correspondto an application module or an application browser. Alternatively, theapplication processor may correspond to an HbbTV application. Thenetwork processor may be implemented as a network module. Alternatively,the network processor may correspond to a WebSocket server. When thenetwork processor is implemented as the WebSocket server, each of theapplication processor and the companion device may be regarded as oneclient. Alternatively, each of a first client and a second client may bereferred to as a peer.

The application processor may transmit information about an electronicdevice operating in the network processor or host request headerinformation indicating companion device information to the networkprocessor. In addition, in response to a connection request from theapplication processor, the network processor may generate a stream headof the application processor and include the stream head in a streamhead group. Upon receiving a connection request from the companiondevice, the network processor may generate a stream head of thecompanion device and connect the generated stream head to a stream headof an application processor matched from a stream head group. In thisinstance, the network processor may remove the stream head of thematched application processor or the stream head of the companion devicefrom the stream head group. Meanwhile, the application processor maytransmit an IP address of a companion device to be connected, andrespective applications may use the same port.

In S1220, the electronic device may exchange data with the companiondevice. Through this process, the electronic device may be connected tothe companion device to perform communication.

The electronic device and the control method according to thespecification are not restricted to configurations and methods of theabove-described embodiments, and all or some of the respectiveembodiments may be selectively combined and variously changed.

FIG. 53 is a block diagram illustrating a main physical device and acompanion physical device according to an embodiment of the presentinvention.

The embodiment of the present invention can provide a service guide in aterrestrial broadcast environment or a mobile broadcast environment. Inaddition, the embodiment of the present invention can provide a serviceguide regarding services available in the next generation hybridbroadcast environment based on interaction between a terrestrialbroadcast network and the Internet.

The embodiment of the present invention can inform users of not onlyvarious services available in the next generation hybrid broadcastsystem, but also constituent content of the services and/or componentelements of the services. As a result, the user can easily confirm,select, and view the corresponding service, resulting in increased userconvenience.

The embodiment of the present invention may construct a single service,various constituent content of the service, and/or component elements ofthe service, and may make a cross reference to each other. As a result,the broadcast receiver can easily construct and provide thecorresponding service, and can allow the user to easily recognize thecorresponding service.

The embodiments of the present invention can extend the referencestructure for linking one service to various content and/or componentelements of the service, and can allow the broadcast receiver and/or theuser to reduce the amount of resources and/or consumption time needed tosearch for content and/or component elements of the single service.

FIG. 53 is a block diagram illustrating a main physical device and acompanion physical device according to an embodiment of the presentinvention.

The main physical device (L25010) according to an embodiment of thepresent invention is one of devices for interactive services, and mayindicate a target device to be controlled by the companion physicaldevice (L25020). The main physical device may be referred to as a maindevice, a main reception device, a main display, a main screen, or thelike.

The main physical device (L25010) according to one embodiment of thepresent invention may include a broadcast interface (L25030), a networkinterface (L25040), a memory unit (L25050), a control unit (L25060), adisplay unit (L25070), a multimedia module (L25080), a storage unit(L25090), a power-supply unit (L25100), and/or a user input interface(L25110).

The broadcast interface (L25030) may indicate a physical device locatedbetween the broadcaster and the device, such that the broadcastinterface (L25030) acting as the physical device can transmit variousmessages (such as the AV stream, service guide, and notificationmessages) and/or data. The broadcast interface (L25030) may receivebroadcast signals, signaling information, data, etc. from thebroadcaster.

The network interface (L25040) may indicate a physical device locatedbetween various devices (e.g., the main physical device and thecompanion physical device), such that the network interface (L25040) cantransmit various messages (e.g., commands, requests, actions, responsemessages, etc.), and can perform advertising and/or data transmission.The network interface may receive broadcast services, broadcast content,signaling information, applications, data, etc. from the Internetservice provider.

The memory unit (L25050) may be an optional or selective deviceimplemented in various types of devices, and may indicate a volatilephysical device capable of temporarily storing various types of data.

The control unit (L25060) may be configured to control the entireoperation of the source device and/or the sink device, and may beimplemented by software or hardware. In this case, the source device mayindicate a device configured to transmit messages and/or data. The sinkdevice may indicate a device configured to receive messages and/or data.Therefore, the main physical device and the companion physical deviceaccording to the embodiment of the present invention may correspond tothe source device or the sink device.

The display unit (L25070) may display data received through the networkinterface or data stored in the storage unit on the screen. In thiscase, the display unit may be controlled by the control unit.

The multimedia module (L25080) may reproduce various types ofmultimedia. The multimedia module may be contained in the control unit,and may be located independently of the control unit.

The storage unit (L25090) may indicate a non-volatile physical devicecapable of storing various types of data therein. For example, the SCcard may correspond to the storage unit.

The power-supply unit (L25100) may receive the external power-supplyvoltage and/or the internal power-supply voltage under control of thecontrol unit, such that the power-supply unit (L25100) can provide apower-supply voltage needed to operate other constituent elements.

The user input interface (L25110) may indicate a device capable ofreceiving input signals or commands from the user.

The companion physical device (L25020) according to the embodiment ofthe present invention may be one of devices needed for interactiveservices, and may indicate a device configured to control the maindevice. Generally, the companion physical device may directly receiveinput signals from the user. The companion physical device may bereferred to as a companion device, a second device, an additionaldevice, an auxiliary device, a companion reception device, a companionreceiver, a companion display, a second screen, or the like.

The physical device (L25020) according to the embodiment of the presentinvention may include a network interface, a memory unit, a controlunit, a display unit, a multimedia module, a storage unit, apower-supply unit, and/or a user input interface.

From among all the constituent elements of the companion physical deviceaccording to the embodiment, some constituent elements having the samenames as those of the main device may have the same functions as thoseof the constituent elements of the above-mentioned main device.

FIG. 54 is a block diagram illustrating a protocol stack configured tosupport a hybrid broadcast service according to an embodiment of thepresent invention.

A physical layer may receive terrestrial broadcast signals, and mayproperly convert (or transform) the received terrestrial broadcastsignals.

IP (Internet Protocol) Encapsulation may acquire an IP datagram usinginformation acquired from the physical layer. In addition, the IPencapsulation may convert (or transform) the acquired IP datagram into aspecific frame (e.g., RS Frame, GSE, etc.)

MPEG2 TS Encapsulation may acquire the MPEG2 TS using informationacquired from the physical layer. In addition, the MPEG2 TSEncapsulation may convert the acquired MPEG2 TS datagram into a specificframe (e.g., RS Frame, GSE, etc.).

A Fast Information Channel (FIC) may transmit specific information(e.g., mapping information between the service ID and the frame) so asto access the service and/or content.

Signaling may include signaling information to support a hybridbroadcast service according to an embodiment of the present invention.This signaling information may include signaling information to supportefficient acquisition of the services and/or content. This signalinginformation may be denoted in binary and/or XML format, and may betransmitted through the terrestrial broadcast network and/or thebroadband network.

Real time A/V (Audio/Video) content and data may be represented by ISOBase Media File Format (ISOBMFF) or the like, and may be transmitted inreal time through the terrestrial broadcast network and/or the broadbandnetwork. Non-real time content may be transmitted on the basis ofIP/UDP/FLUTE. Real-time broadcast A/V (Audio/Video) content, data and/orsignaling information may be transmitted in real time through theInternet. In this case, the real-time broadcast A/V (Audio/Video)content, data and/or signaling information may be transmitted by arequest message. Alternatively, the real-time broadcast A/V(Audio/Video) content, data and/or signaling information may also betransmitted through real-time streaming.

The embodiment of the present invention may combine data through theabove-mentioned protocol stack, and may also provide various enhancedservices, for example, an interactive service, a second screen service,etc.

FIG. 55 is a view showing an UPnP type Action mechanism according to anembodiment of the present invention.

First, communication between devices in the present invention will bedescribed.

The communication between devices may mean exchange of amessage/command/call/action/request/response between the devices.

In order to stably transmit a message between devices to a desireddevice, various protocols, such as Internet Control Message Protocol(ICMP) and Internet Group Management Protocol (IGMP), as well asInternet Protocol (IP) may be applied. At this time, the presentinvention is not limited to a specific protocol.

In order to contain various information in a message used forcommunication between devices, various protocols, such as HypertextTransfer Protocol (HTTP), Real-time Transport Protocol (RTP), ExtensibleMessaging and Presence Protocol (XMPP), and File Transfer Protocol(FTP), may be applied. At this time, the present invention is notlimited to a specific protocol.

When a message used for communication between devices is transmitted,various components, such as a message header and a message body, definedby each protocol may be utilized. That is, each message component may betransmitted in a state in which data are stored in each messagecomponent and the present invention is not limited to a specific messagecomponent. In addition, data transmitted by a message may be transmittedvarious types (string, integer, floating point, boolean, character,array, list, etc.) defined by each protocol. In order to structurallyexpress/transmit/store complex data, a Markup scheme, such as ExtensibleMarkup Language (XML), Hypertext Markup Language (HTML), ExtensibleHypertext Markup Language (XHTML), and JavaScript Object Notation(JSON), text, or an image format may be applied. At this time, thepresent invention is not limited to a specific scheme.

In addition, a message used for communication between devices may betransmitted in a state in which data are compressed. The presentinvention is not limited to application of a specific compressiontechnology.

In the description of the above-described communication between devicesin the present invention, one scheme, e.g. a UPnP scheme, will bedescribed. The UPnP scheme may correspond to a case in whichIP-TCP/UDP-HTTP protocols are combined in the description of theabove-described communication between devices.

The UPnP type Action mechanism according to the embodiment of thepresent invention shown in the figure may mean a communication mechanismbetween a UPnP control point and a UPnP device. The UPnP control pointt87010 may be an HTTP client and the UPnP device t87020 may be an HTTPserver. The UPnP control point t87010 may transmit a kind of messagecalled an action to the UPnP device t87020 such that the UPnP devicet87020 can perform a specific action.

The UPnP control point t87010 and the UPnP device t87020 may be pairedwith each other. Pairing may be performed between the respective devicesthrough a discovery and description transmission procedure. The UPnPcontrol point may acquire a URL through a pairing procedure.

The UPnP control point t87010 may express each action in an XML form.The UPnP control point t87010 may transmit each action to the acquiredcontrol URL using a POST method t87030 defined by HTTP. Each action maybe data which are to be actually transmitted as a kind of message. Thismay be transmitted to a HTTP POST message body in an XML form. Eachaction may include name, arguments, and relevant data. The HTTP POSTmessage body may transmit name and/or arguments of each action.

At this time, each action may be transmitted to the same control URL.The UPnP device t87020 may parse the received action using an XMLparser. The UPnP device t87020 may perform a corresponding operationaccording to each parsed action.

For the UPnP protocol, each action may be defined by name and used. Inaddition, since the name of the action is also transmitted to the HTTPPOST message body, exchange between infinite kinds of actions may bepossible even in a case in which only one URL for a target device existsand only one HTTP POST method is used.

FIG. 56 is a view showing a REST mechanism according to an embodiment ofthe present invention.

In the description of the above-described communication between devicesin the present invention, one scheme, e.g. a REST scheme, will bedescribed.

The REST mechanism according to the embodiment of the present inventionshown in the figure may mean a communication mechanism between a RESTclient t88010 and a REST server t88020. The REST client t88010 may be anHTTP client and the REST server t88020 may be an HTTP server. In thesame manner as in the above description, the REST client t88010 maytransmit a kind of message called an action to the REST server t88020such that the REST server t88020 can perform a specific action.

In this embodiment, the REST client t88010 may transmit each action tothe REST server t88020 through a URI. Action name is not required foreach action. Each action may include only arguments and data.

Among HTTP methods, various methods, such as GET, HEAD, PUT, DELETE,TRACE, OPTIONS, CONNECT, and PATCH, as well as POST may be utilized. Inaddition, a plurality of URIs that will access a target device forcommunication may be defined. Due to such characteristics, an action maybe transmitted without definition of action name. A plurality of URIvalues necessary for such a REST scheme may be acquired during adiscovery or description transmittance procedure.

Data or arguments necessary to be transmitted may be transmitted whilebeing added to a corresponding URI. Alternatively, data or arguments maybe transmitted while being included in the HTTP body in various forms(XML, JSON, HTML, TEXT, IMAGE, etc.).

The REST server t88020 may perform a specific operation according to thereceived action.

The above-described communication between devices is only an embodimentand all of the details proposed by the present invention are not limitedto the UPnP scheme.

FIG. 57 is a diagram illustrating a service for exchanging electronicservice guide (ESG) between a broadcast receiver and companion devicesaccording to an embodiment of the present invention.

ESG may be a type of channel or information to be transmitted throughservice guide delivery descriptors in a specific session and may provideservice guide of broadcast, radio, or other media applications. ESG mayprovide service scheduling or program related information items in theform of menu format, etc. to a user. ESG may be provided through abroadcast channel or an Internet channel (broadband).

Users may perform an operation such as service providing schedule,discovery of an entry point of currently available services, and servicefiltering according to preference, through ESG. Content providers mayrepresent information on a service and/or content that are available,purchase/subscription related information, and service accessinformation, through ESG. The ESG may also be referred to as serviceguide, electronic program guide (EPG), or the like.

Conventionally, when service guide such as ESG is executed while a userwatches a broadcast program through a broadcast receiver, ESG may behidden by the watched broadcast program to cause inconvenience.

The present invention proposes a method of executing service guides suchas ESG in a companion device to access ESG information withoutobstructing watch of the currently watched broadcast program. In thiscase, a user may access ESG while does not experience inconvenienceduring watching of a broadcast program. The user may protect his or herprivacy using a personal companion device for ESG search. In general,ESG may be searched for through a UI of a companion device instead of aUI of a broadcast receiver with degraded convenience, thereby enhancingconvenience.

The present invention may overcome the aforementioned problem bydefining a protocol for transmitting ESG information to a companiondevice from a broadcast receiver in a next-generation hybrid broadcastenvironment based on interaction between a terrestrial broadcast networkand the Internet. The present invention proposes a protocol of changinga service of a broadcast receiver by transmitting channel information ina companion device when a user selects a new service through ESGprovided by the companion device.

Although the embodiments of the present invention have been describedbased on UPnP, this is merely for convenience of description and aprotocol for communication between a broadcast receiver and a companiondevice is not limited thereto. Although XML-based ESG has beenexemplified according to the embodiments of the present invention, thisis merely for convenience of description and format for configuring ESGis not limited thereto.

An example of a service for exchanging the illustrated ESG may bereferred to as an ESG service.

The ESG service may be a service for exchanging ESG between a broadcastreceiver and a companion device. In some embodiments, a service type ofan ESG service may be defined as atsc3.0ESG-1 and a service ID may bedefined as urn:atsc.org:serviceId:atsc3. OESG.

Compatibility between services may be required for an ESG service. Insome embodiments, an UPnP device type may be defined. A broadcastreceiver may have a device type of urmatsc.org:device:atsc3.0rcvr andoperate as a UPnP controlled device. A companion device may operate asan UPnP control point.

A state variable, an action, etc. for an ESG service will be describedbelow.

FIG. 58 is a diagram illustrating an ESGData state variable according toan embodiment of the present invention.

For the aforementioned ESG service, the ESGData state variable may bedefined. The ESGData state variable may be a state variable indicatingESG. The ESGData state variable may store ESG data of ESG receivedthrough a broadcast/Internet network. The illustrated ESGData may bewritten in XML format.

The ESGData state variable may store ESG data items indicating ESG, thatis, elements, attributes, and sub elements in ESG.

A Service element t54010 in the ESGData state variable may be an elementhaving information related to a service indicated by ESG among contentsincluded in the ESG. Lower information of the element may includeService@id indicating a service ID, Service@version indicating a serviceversion, Service.Name indicating a service name, Service.Descriptionindicating service description, and/or Service. ServiceType indicating aservice type. Here, A.B may refer to a B element as a lower element ofan A element and A@a may refer to @a as lower attribute of the Aelement.

Here, Service.ServiceType, that is, an ServiceType element as a lowerelement of a service may indicate a service type indicated by acorresponding service. In some embodiments, 0 may be unspecified, 1 mayrefer to Basic TV, 2 may refer to Basic Radio, . . . , 14 may refer to alinear service, 15 may refer to an app based service, and 16 may referto a companion screen service or the like. A value indicated by theelement may be changed in some embodiments.

A Schedule element t54020 in the ESGData state variable may be anelement having schedule information of services/programs indicated byESG among contents included in the ESG. Lower information of the elementmay include Schedule@id indicating a schedule ID, Schedule@versionindicating schedule version, and so on. Lower information of the elementmay include Scheudle.ServiceReference indicating a service related toschedule, Scheudle.InteractivityDataReference indicating interactivitydata related to schedule, Scheudle.ContentReference indicating contentrelated to schedule, and so on.

A Content element t54030 in the ESGData state variable may be an elementhaving content information indicated by ESG among contents included inthe ESG. Lower information of the element may include Content@idindicating a content ID, Content@version indicating a content version,Content.Name indicating a content name, Content. Description indicatingcontent description, Content. StartTime indicating presentation starttime of content, and/or Content.EndTime indicating presentation end timeof content. ComponentReference as a lower element of the Content elementmay include information for referencing a component of correspondingcontent, related to the corresponding content. Thereby, the relatedcomponent may be recognized and corresponding component relatedinformation items in ESG may be referenced.

A Component element t54040 in the ESGData state variable may be anelement having component information of content indicated by ESG amongcontents included in the ESG. Lower information of the element mayinclude Component@id indicating a component ID, Component@versionindicating a component version, and so on. Lower information of theelement may include Language indicating a component language, Lengthindicating a component length, ParentalRating indicating componentrating, ComponentType indicating a component type, ComponentRoleindicating a component role, TargetDevice indicating a device targetedby a component, and so on. According to whether a component is apresentable video, audio, closed caption, or app, information such asPresentableVideoComponent, PresentableAudioComponent,PresentableCCComponent, and PresentableAppComponent may be included inthe element, respectively.

In some embodiments, the ESGData state variable may be transmitted to acompanion device using an eventing method or an action method.

The aforementioned element, attributes, and so on are merely embodimentsof ESGData and element/attributes, etc. in ESGData may be further added,modified, or deleted according to configuration, format, etc. of ESG.

FIG. 59 is a diagram illustrating an ESGData state variable according toanother embodiment of the present invention.

The illustrated ESGData state variable is similar to the aforementionedESGData state variable but is different from the aforementioned ESGDatastate variable in that the Component element is included as a lowerelement of the Content element.

A plurality of components are combined to constitute one content and,thus, the Component element may be included as a lower element of theContent element. Capability of devices for supporting each component maybe defined as DeviceCapability as a lower element and may be included asa lower element of a Component element.

FIG. 60 is a diagram illustrating an operation of transmitting anESGData state variable to a companion device (CD) using an eventingmethod according to an embodiment of the present invention.

First, the illustrated DC may refer to a companion device and a primarydevice (PD) may refer to a receiver or a broadcast receiver. Accordingto the present embodiment, the two devices are assumed to be paired witheach other. The companion device is assumed to subscribe to theaforementioned ESG service. In this initial state t56010, the ESGDatastate variable may not have any value.

A service/content provider may transmit ESG through a broadcast networkor a broadband channel (t56020). The ESG may be received through anetwork interface or a receiving unit of a receiver. Here, the receivingunit may be the aforementioned broadcast interface or tuner.

The receiver may signal the received ESG (t56030). The ESG data may bestored in the ESGData state variable (t56040).

The ESGData may be transmitted to the companion device through eventing(t56050). The companion device that receives the ESGData state variablemay parse the ESGData (t56060) and ESG may be exposed to the companiondevice through a UI according to the parsed value (t56070). In thiscase, in order to show the ESG to the user, the UI may be represented ata native level of the companion device or represented in an applicationof the companion device.

There may be various exemplary embodiments of a method of representingESG by a companion device. In some embodiments, upon receiving ESG, thecompanion device may immediately expose ESG to the user in any form.According to another embodiment of the present invention, upon receivingESG, the companion device may transmit a notification message to a user,and when the user executes the notification message, ESG may be exposed.According to another embodiment of the present invention, upon receivingthe ESG, the companion device owns ESG information in a background andthen the user executes an application in which ESG is viewable at a timedesired by a user, the ESG may be exposed to the user at last.

FIG. 61 is a diagram illustrating LastChangedESGData state variableaccording to an embodiment of the present invention.

For the aforementioned ESG service, the LastChangedESGData statevariable may be defined. As described above, when an entire portion ofESG is transmitted to a companion device, even if even some ESG dataitems are modified, it may not be effective that all ESG data items aretransmitted. To this end, the LastChangedESGData state variable forstoring only the modified ESG data may be defined. TheLastChangedESGData state variable may store only ESG data that isadded/modified/deleted in newly received ESG compared with previous ESG.

The LastChangedESGData state variable may include an Addition element(t57010). The element may store ESG data added to the newly received ESGcompared with existing ESG data. As a sub element of the element, newlyadded ESG data items, i.e., element/attributes may be stored. Forexample, when ESG data related to a new service with a new service IDcompared with existing ESG data is added to newly received ESG,element/attributes related to the new service may be included in a lowertree of the Addition element. In the illustrated embodiment, a servicewith an ID of “atsc.org/esg/service/3 is newly added and, thus, it maybe seen that a Service element of a corresponding service is included inthe Addition element. In addition, a service with an ID of“atsc.org/esg/service/4 and a name of ABC is newly added and, thus, itmay be seen that the Service element of the corresponding service isadded to the Addition element. In addition, information such as Service,Content, and Schedule may be included in the element.

The LastChangedESGData state variable may include an elementModification (t57020). The element may store ESG data modified in newlyreceived ESG compared with existing ESG data. As a sub element of theelement, the modified ESG data items, that is, element/attributes may bestored. For example, when any one of lower information items of schedulewith an ID of “atsc.org/esg/schedule/3” is modified, an element Scheduleof corresponding schedule may be stored in the element Modification. Inaddition, information such as Service, Content, and Schedule may beincluded in the element.

The LastChangedESGData state variable may include an element Deletion(t57030). The element may store ESG data deleted in newly received ESGcompared with existing ESG data. As a sub element of the element, thedeleted ESG data items, that is, element/attributes may be stored. Forexample, when the Content element with an ID of “atsc.org/esg/content/1”and “atsc.org/esg/content/2” is deleted in newly received ESG, theContent element of corresponding content may be stored in an elementDeletion. In addition, information such as Service, Content, andSchedule may be included in the element.

In some embodiments, the LastChangedESGData state variable may betransmitted to a companion device using an eventing method or an actionmethod. When the state variable is transmitted using the eventingmethod, if a value of the state variable is modified, the state variablemay be transmitted to the companion device. When the state variable istransmitted using the action method, the LastChangedESGData statevariable may be configured with respect to mostly recently modifiedcontent of ESG data at a time of receiving a request for the value ofthe state variable and transmitted to the companion device.

The companion device may update only the modified ESG data itemscompared with pre-stored ESG with respect to the receivedLastChangedESGData state variable. Thereby, effective transmission maybe performed compared with the case in which an entire portion of ESG istransmitted.

The aforementioned element, attributes, and so on are merely embodimentsof LastChangedESGData and element/attributes, etc. in LastChangedESGDatamay be further added, modified, or deleted according to configuration,format, etc. of ESG.

FIG. 62 is an operation of transmitting ESG data to a companion deviceaccording to a GetESGData action according to an embodiment of thepresent invention.

As described above, an ESGData state variable may be transmitted to thecompanion device using an eventing method. However, when a receivertransmits ESG data to the companion device using an eventing methodwhenever ESG is modified, this results in network overload and a burdento the companion device. Accordingly, a GetESGData( ) action may bedefined to transmit ESG data only when the companion device wants this.

The GetESGData( ) action may be an action for transmitting the ESGDatastate variable to the companion device using an action method. That is,when the companion device makes a request for ESG data to the receiverthrough the action, the receiver may transmit the ESGData state variableto companion data. An input argument of the action may be none and anoutput argument may be the ESGData state variable.

The GetESGData( ) action may be performed when a user wants to see ESGthrough the companion device and an ESG application, etc. are executed.In this case, ESG data may be received as a result of the correspondingaction and the received ESG data may be exposed through the ESGapplication. In some embodiments, when the GetESGData( ) action isexecuted using a periodic polling method to store ESG data in thecompanion device and, then, the ESG application is executed, the storedESG data may be exposed to the user.

The GetESGData( ) action may also be simultaneously supported when theESGData state variable supports an eventing method. However, in thiscase, when ESG data is received using an eventing method and,simultaneously, ESG data is also received using an action wheneverESGData is modified, ESG data may be redundantly received. Accordingly,when the action method and the eventing method are simultaneouslysupported, a policy of receiving ESG data using an eventing method onlywhen a first ESG service is subscribed and, then, receiving ESG datausing the GetESGData( ) action periodically or when an ESG applicationis executed.

First, in the present embodiment, two devices are assumed to be alreadypaired with each other. In addition, the companion device is assumed tosubscribe the aforementioned ESG service.

The receiver may have own ESG data (t58010). The ESG data may be storedin the ESGData state variable. A user may take a specific action ofexecuting an ESG application (t58020). The specific action may be anoperation that requires ESG data.

The companion device may perform the GetESGData( ) action to make arequest for the ESGData state variable to the receiver (t58030). Thereceiver may simultaneously output the ESGData state variable as anoutput argument of the GetESGData( ) action to the companion devicewhile transmitting call back of 200 OK in response to the request(t58040).

The companion device may perform an operation of parsing the receivedESGData and exposing the ESGData through an ESG application using theESG data (t58050). The companion device may perform an operation ofimmediately exposing ESG data or storing the ESG data once in order toexpose the ESG data, like in the aforementioned embodiments.

The illustrated embodiment may be an embodiment of performing theGetESGData( ) action when the user performs a specific action. However,in some embodiments, as described above, when the GetESGData( ) actionis periodically performed (irrespective of whether the specific actionis performed) and, then, the user executes the ESG application or thelike at a predetermined time, ESG data that has been received and storedthrough the corresponding action may be exposed.

FIG. 63 is a diagram illustrating an operation of transmitting ESG datato a companion device according to a GetServiceIds action or aGetESGbyServiceIds action according to an embodiment of the presentinvention.

In order to minimize a network burden between a broadcast receiver and acompanion device and/or a burden used to process entire ESG data by thecompanion device, only ESG data related to a specific service may betransmitted to the companion device. To this end, a ServiceIdsList statevariable and a A_ARG_TYPE_ESGData_by_ServiceIds state variable may bedefined.

The ServiceIdsList state variable may be a state variable fortransmitting IDs of services described by ESG to the companion device.That is, the state variable may include service ID information itemsamong ESG data items that have been parsed and stored by the receiver.The state variable may have a type of a list of strings or a list ofURIs. Here, any type of URI may be used. In some embodiments, the statevariable may be represented in the form of CSV. For example, the statevariable may be represented according to atsc. org/esg/service/1 ,atsc.org/esg/service/2, . . . , etc.

The A_ARG_TYPE_ESGData_by_ServiceIds state variable may be a statevariable for storing some ESG data of ESG. The state variable may bedefined to transmit only some ESG data to the companion device. Thestate variable may have a fragment type of a specific form of MarkupLanguage for representing the ESGData state variable. For example, whenthe ESGData state variable is an XML document, the state variable mayhave an XML fragment type.

Service IDs of ESG owned by the receiver may be first transmitted to thecompanion device using the aforementioned state variables and,accordingly, only the requested required ESG data may be transmitted tothe companion device. To this end, a GetServiceIds action and aGetESGbyServiceIds action may be defined.

The GetServiceIds action may be an action of receiving IDs of a servicefrom the receiver by the companion device. The receiver may transmitservice IDs in the form of a list to the companion device amonginformation items on a service described by ESG owned by the receiver.An input argument of the action may be none and an output argument maybe the ServiceIdsList state variable.

The GetServiceIds action may be performed when a user wants to see ESGthrough the companion device and an ESG application, etc. are executed.In this case, ESG data may be received as a result of the correspondingaction and the received ESG data may be exposed through the ESGapplication. In some embodiments, when the GetServiceIds action isexecuted using a periodic polling method to store ESG data in thecompanion device and, then, the ESG application is executed, the storedESG data may be exposed to the user.

The GetESGbyServiceIds action may be defined to receive only ESG datacorresponding to a specific service from the receiver by the companiondevice. The companion device may select a service ID of a desiredservice using a list of service IDs received through the GetServiceIdsaction. Then, the action may be performed using a list of service IDsusing an input argument in order to receive ESG data of a desiredservice. As a result, the companion device may receive ESG data about adesired service. An input argument of the action may be a ServiceIdsListstate variable and an output argument may be anA_ART_TYPE_ESGData_by_ServiceIds state variable.

The GetESGbyServiceIds action may be performed when an ESG application,etc. are executed if a user wants to see ESG through the companiondevice. In this case, ESG data may be received as a result of thecorresponding action and the received ESG data may be exposed throughthe ESG application. In some embodiments, when the GetESGbyServiceIdsaction is executed using a periodic polling method to store ESG data inthe companion device and, then, the ESG application is executed, thestored ESG data may be exposed to the user.

In some embodiments, when an input argument is set as “*” in theGetESGbyServiceIds action, all ESG data items may be set to be requestedirrespective of a service ID. In some embodiments, when an inputargument is set as “empty” in the GetESGbyServiceIds action, ESG dataabout a currently watched service may be set to be requested.

According to the present embodiment, the two devices are assumed to bepaired with each other. The companion device is assumed to subscribe tothe aforementioned ESG service.

The receiver may own ESG data (t59010). The ESG data may be stored inthe ESGData state variable. The ESG data stored in ESGData may be ESGdata about two services identified according to “atsc.org/esg/service/1”or “atsc.org/esg/service/2” (t59080). A user may take a specific actionof executing an ESG application (t59020). The specific action may be anoperation that requires ESG data.

The companion device may make a request for a list of service IDsthrough the GetServiceIds action (t59030). The receiver may outputServiceIdsList to the companion device along with 200 OK (t59040).According to the present embodiment, a value of ServiceIdsList may bethe same as (atsc.org/esg/service/1, atsc.org/esg/service/2).

When a specific service desired by a user or a companion device is aservice identified according to “atsc.org/esg/service/1”, theGetESGbyServiceIds action may be performed using the service ID as aninput argument (t59050). The receiver may outputA_ART_TYPE_ESGData_by_ServiceIds to the companion device along with 200OK (t59060). In the present embodiment, a value ofA_ART_TYPE_ESGData_by_ServiceIds may be ESG data related to a serviceidentified according to “atsc.org/esg/service/1” (t59090). Asillustrated in the drawing, the output argument may include a Scheduleelement having atsc.org/esg/service/1 as a reference value and a Contentelement as well as a Service element having atsc.org/esg/service/1 as aservice ID value. Here, the Schedule element and the Content element maybe schedule and content information related to a service identifiedaccording to atsc.org/esg/service/1.

The companion device may perform an operation of parsing the receivedESG data and exposing the ESG data through an ESG application using theESG data (t59070). The companion device may perform an operation ofimmediately exposing ESG data or storing the ESG data once in order toexpose the ESG data, like in the aforementioned embodiments.

The illustrated embodiment may be a case in which a user performs thespecific action but, as described above, when the action may be firstperformed (irrespective of whether the specific action is performed)and, then, the user executes the ESG application, etc. at apredetermined time, ESG data that has been received and stored throughthe corresponding action may be exposed.

FIG. 64 is a diagram illustrating an operation of transmitting ESG datato a companion device according to a GetCurrentServiceId actionaccording to an embodiment of the present invention.

It may be needed to transmit ESG data about a currently watched servicein a receiver to the companion device. To this end, a service ID of thecurrently watched service may be transmitted to the companion device. Tothis end, a CurrentServiceId state variable and a GetCurrentServiceIdaction may be defined.

The CurrentServiceId state variable may store a service ID of acurrently watched service in a receiver among ESG data items of thereceiver. The state variable may be a string or specific URI type.

The GetCurrentServiceId action may be an action for receiving a serviceID of a currently watched service in a receiver by the companion device.An input argument of the action may be none and an output argument maybe the CurrentServiceId state variable.

The GetCurrentServiceId action may be performed when a user wants to seeESG through the companion device and an ESG application, etc. areexecuted. In this case, ESG data may be received as a result of thecorresponding action and the received ESG data may be exposed throughthe ESG application. In some embodiments, when the GetCurrentServiceIdaction is executed using a periodic polling method to store ESG data inthe companion device and, then, the ESG application is executed, thestored ESG data may be exposed to the user.

According to the present embodiment, the two devices are assumed to bepaired with each other. The companion device is assumed to subscribe tothe aforementioned ESG service.

The receiver may own ESG data (t60010). The ESG data may be stored inthe ESGData state variable. The ESG data stored in ESGData may be ESGdata about two services identified according to “atsc.org/esg/service/1”or “atsc.org/esg/service/2” (t60090). The receiver may periodicallysignal currently watched broadcast and update a service ID of acurrently watched service to the CurrentServiceId state variable. Theuser may take a specific action of executing an ESG application(t60030). The specific action may be an operation that requires ESGdata.

The companion device may make a request for an ID of a currently watchedservice through the GetCurrentServiceId action (t60040). The receivermay output the CurrentServiceId state variable to the companion devicealong with 200 OK (t60050). According to the present embodiment, a valueof the CurrentServiceId state variable may be “atsc. org/esg/service/1”.

The companion device may perform the GetESGbyServiceIds action to make arequest for ESG data related to a currently watched service (t60060).According to the present embodiment, an input argument of theGetESGbyServiceIds action may be atsc.org/esg/service/1. The receivermay output the A_ART_TYPE_ESGData_by_ServiceIds state variable to thecompanion device along with 200 OK (t60070). According to the presentembodiment, a value of the A_ART_TYPE_ESGData_by_ServiceIds may be ESGdata related to a service identified according to“atsc.org/esg/service/1” (t60100). As illustrated in the drawing, anoutput argument may include a Schedule element havingatsc.org/esg/service/1 as a reference value and a Content element aswell as a Service element having atsc.org/esg/service/1 as a service IDvalue. Here, the Schedule element and the Content element may beschedule and content information related to a service identifiedaccording to atsc.org/esg/service/1.

The companion device may perform an operation of parsing the receivedESG data and exposing the ESG data through an ESG application using theESG data (t60080). The companion device may perform an operation ofimmediately exposing ESG data or storing the ESG data once in order toexpose the ESG data, like in the aforementioned embodiments.

The illustrated embodiment may be a case in which a user performs thespecific action but, as described above, when the action may be firstperformed (irrespective of whether the specific action is performed)and, then, the user executes the ESG application, etc. at apredetermined time, ESG data that has been pre-received and storedthrough the corresponding action may be exposed.

FIG. 65 is a diagram illustrating an operation of transmitting ESG datato a companion device according to a SearchESG action according to anembodiment of the present invention.

Upon making a request for ESG data to the receiver, the companion devicemay make a request for corresponding ESG data only when a specific fieldof the ESG data has a specific value (target value). To this end, theA_ART_TYPE_SearchField state variable, the A_ART_TYPE_TargetValue statevariable, and the SearchESG action may be defined.

The A_ART_TYPE_SearchField state variable may indicate a specific fieldto be determined by the companion device. That is, the state variablemay be a list of names of element/attributes of the ESGData statevariable. For example, a value of the Service@id, Service.Genre, etc.may be stored in the state variable. The state variable may have a listtype of strings. The state variable may also be referred to asSearchField.

The A_ART_TYPE_TargetValue state variable may store a specific value ofa specific field determined by the companion device, that is, a targetvalue. The target value may be used to determine whether the determinedspecific field has the corresponding target value. ESG data may besearched for using the target value. The state variable may have a listtype of strings. The state variable may also be referred to asTargetValue.

The SearchESG action may be an action for searching for and making arequest for ESG data in the receiver by the companion device. As aninput argument of the action, a specific field (SearchField) and/or atarget value (TargetValue) may be defined. The receiver may search forESG data according to whether the corresponding specific field has acorresponding target value. Upon searching for ESG data that satisfies acorresponding condition, the receiver may output all related ESG dataitems to the companion device. When any data is not matched, no data maybe output. In some embodiments, only some ESG data items are matched,ESG information may also be transmitted.

As an output argument, the A_ART_TYPE_ESGData state variable may bedefined and may be a state variable for storing some ESG data items ofESG like the aforementioned A_ART_TYPE_ESGData by ServiceIds statevariable. The A_ART_TYPE_ESGData state variable may also be referred toas SearchedESGData.

The SearchESG action may be performed when a user wants to see ESGthrough the companion device and an ESG application, etc. are executed.In this case, ESG data may be received as a result of the correspondingaction and the received ESG data may be exposed through the ESGapplication. In some embodiments, when the SearchESG action is executedusing a periodic polling method to store ESG data in the companiondevice and, then, the ESG application is executed, the stored ESG datamay be exposed to the user.

First, in the present embodiment, two devices are assumed to be alreadypaired with each other. In addition, the companion device is assumed tosubscribe the aforementioned ESG service.

The receiver may have own ESG data (t61010). The ESG data may be storedin the ESGData state variable. ESG data stored in the ESGData may be ESGdata about a service identified according to “atsc.org/esg/service/1”and having a Service.Genre value of Drama and a service identifiedaccording to “atsc.org/esg/service/2” and having a Service. Genre valueof Sports (t61050).

The companion device may make a request for ESG data using the SearchESGaction (t61020). Here, an input argument of the corresponding action maybe the same as (“Service@id, Service.Genre”, “atsc.org/esg/service/1,Drama”). This is used to search for ESG data with a service ID ofatsc.org/esg/service/1 and Drama as a value of sub element Genre of theService element.

The receiver may search for ESG data matched with a correspondingcondition and output the corresponding ESG data to the companion devicealong with 200 OK (t61030). In the present embodiment, ESG data relatedto a service identified according to “atsc.org/esg/service/1” matchedwith the corresponding condition may be output.

The companion device may perform an operation of parsing the receivedESG data and exposing the ESG data through an ESG application using theESG data (t61040). The companion device may perform an operation ofimmediately exposing ESG data or storing the ESG data once in order toexpose the ESG data, like in the aforementioned embodiments.

FIG. 66 is a diagram illustrating an authentication procedure oftransmitting ESG data according to a DoAuthenticationForESG actionaccording to an embodiment of the present invention.

During exchange of ESG data between a receiver and a companion device,an unintended application, for example, an application for hacking maymake a request for ESG information. In order to prevent this,authentication procedure for security may be required. To this end, aCompanionDeviceId state variable, a CompanionDeviceAppId state variable,a CompanionDeviceAppVersion state variable, a PrimaryDeviceId statevariable, and a DoAuthenticationForESG action may be defined.

The CompanionDeviceId state variable may be a state variable for storingID information of the companion device. A unique value for identifyingthe companion device may be stored in the state variable. As a deviceID, a MAC address or the like may be used and may also be encrypted forsecurity (e.g. hashed Mac address). The state variable may be a stringor a specific URI type.

The CompanionDeviceAppId state variable may be a state variable forstoring ID information of an application to be executed to use ESG bythe companion device. Here, the application may be a concept includingboth a native app of the companion device and a browser-based app. Thestate variable may be a string or a specific URI type.

The CompanionDeviceAppVersion state variable may be a state variable forstoring version information of an application to be executed to use ESGby the companion device. The receiver may determine whether ESGinformation is provided using the version information. The statevariable may be a hexBinary or integer type.

The PrimaryDeviceId state variable may be a state variable for storingdevice ID information of a receiver, that is, a primary device. Thecompanion device may identify the receiver using the state variable. Thecompanion device may determine whether received information is from anunintended receiver or whether a searched receiver is a specificreceiver that has made a request for ESG when a plurality of receiversare searched in a home network, using the state variable. The statevariable may be a string or a specific URI type.

The DoAuthenticationForESG action may be an action for performing anauthentication procedure for security before the companion device makesa request for ESG data to a receiver. Through the authenticationprocedure, whether ESG data is permitted to be exchanged may bedetermined. As an input argument, an ID of the companion device, an appID of the companion device, and/or app version information of thecompanion device may be input and transmitted to the receiver. Theinformation items may be referred to as authentication information. Uponreceiving the authentication information, the receiver may determinewhether a companion device or an app for ESG makes a request for theauthentication information. Upon receiving an app of a normal companiondevice, the receiver may output a device ID of the receiver to thecompanion device. The companion device may check whether the receiver isa target to which the companion device makes a request for ESG withreference to the received ID of the receiver. After the authenticationprocedure is terminated, actual ESG data may be receive according to amechanism such as action/eventing proposed according to the presentinvention. An input argument of the action may be states variables ofCompanionDeviceId, CompanionDeviceAppId, and CompanionDeviceAppVersionand an output argument of the action may be a PrimaryDeviceId statevariable.

The DoAuthenticationForESG action may be performed when a user wants tosee ESG through the companion device and an ESG application, etc. areexecuted. In some embodiments, the DoAuthenticationForESG action may beperformed using a periodic polling method and an authenticationprocedure may be performed.

According to the present embodiment, the two devices are assumed to bepaired with each other. The companion device is assumed to subscribe tothe aforementioned ESG service.

The receiver may own ESG data (t62010). The ESG data may be stored inthe state variable ESGData. The user may take a specific action ofexecuting an ESG application (t62020). The specific action may be anoperation that requires ESG data.

The companion device may perform the DoAuthenticationForESG action(t62030). Thereby, authentication information may be transmitted to thereceiver. The receiver may determine whether a corresponding companiondevice is authenticated using the received authentication information(t62040). When the companion device is authenticated, the receiver mayoutput a device ID of the receiver to the companion device along with200 OK (t62050). The companion device may determine whether thecompanion device is a receiver that is permitted to make a request forESG data using the received ID of the receiver (t62060).

Then, in some embodiments, the companion device may make a request forand receive ESG data (t62070 and t62080). The companion device mayperform an operation of parsing the received ESG data and exposing theESG data through an ESG application using the ESG data (t62070). Thecompanion device may perform an operation of immediately exposing ESGdata or storing the ESG data once in order to expose the ESG data, likein the aforementioned embodiments.

The illustrated embodiment may be a case in which a user performs thespecific action but, as described above, when the action may be firstperformed (irrespective of whether the specific action is performed)and, then, the user executes the ESG application, etc. at apredetermined time, the authentication procedure is already terminatedand, thus, operations of transmitting ESG data may be immediatelyperformed.

FIG. 67 is a diagram illustrating an operation of transmitting ESG datato a companion device simultaneously with device authenticationaccording to GetServiceIds and GetESGbyServiceIds actions according toanother embodiment of the present invention.

As described above, a separate action may be defined for authentication.In the present embodiment, existing actions may be extended andauthentication may be performed without definition of a separate actionand, simultaneously, original purpose of the existing actions may beperformed. Here, actions as an extension target may be the all actionsstated in the present invention. With regard to the actions as anextension target, as well as the existing defined an input/outputargument, CompanionDeviceId, CompanionDeviceAppId, andCompanionDeviceAppVersion state variables may be added as an inputargument and a PrimaryDeviceId state variable may be added as an outputargument.

According to the present embodiment, the GetServiceIds action and theGetESGbyServiceIds action may be extended. The present invention may notbe limited only to extension of the corresponding action.

The GetServiceIds action may be extended to have CompanionDeviceId,CompanionDeviceAppId, and CompanionDeviceAppVersion state variables asan input argument and to have a PrimaryDeviceld state variable as wellas an existing ServiceIdsList state variable as an output argument. Uponreceiving authentication information and determining that transmissionis permitted according to the action, the receiver may transmit IDs ofservices along with a device ID of the receiver to the companion device.The companion device may determine whether the received service IDs areavailable with reference to the received device ID of the receiver.

The GetESGbyServiceIds action may be extended to have CompanionDeviceId,CompanionDeviceAppId, and CompanionDeviceAppVersion state variables aswell as an existing ServiceIdsList state variable as an input argumentand to have an existing A_ART_TYPE_ESGData_by_ServiceIds state variableas an output argument. Upon receiving authentication information andservice IDs and determining that transmission is permitted according tothe action, the receiver may transmit ESG data of a related servicealong with a device ID of the receiver to the companion device. Thecompanion device may determine whether the received ESG data isavailable with reference to the received device ID of the receiver.

The extended actions may be performed when a user wants to see ESGthrough the companion device and an ESG application, etc. are executed.In this case, ESG data may be received as a result of the correspondingaction and the received ESG data may be exposed through the ESGapplication. In some embodiments, the extended actions are executedusing a periodic polling method to store ESG data in the companiondevice and, then, the ESG application is executed, the stored ESG datamay be exposed to the user.

First, in the present embodiment, two devices are assumed to be alreadypaired with each other. In addition, the companion device is assumed tosubscribe the aforementioned ESG service.

The receiver may have own ESG data (t63010). The ESG data may be storedin the ESGData state variable. The ESG data stored in ESGData may be ESGdata about two services identified according to “atsc.org/esg/service/1”and “atsc.org/esg/service/2” (t63100). A user may take a specific actionof executing an ESG application (t63020). The specific action may be anoperation that requires ESG data.

The companion device may make a request for a list of service IDsthrough the GetServiceIds action (t63030). In this case, authenticationinformation may also be transmitted to the receiver. The receiver maydetermine whether the companion device is authenticated using theauthentication information (t63040). When the companion device isauthenticated, the receiver may output ServiceIdsList along with 200 OKto the companion device (t63050). According to the present embodiment, avalue of ServiceIdsList may be the same as (atsc.org/esg/service/1,atsc.org/esg/service/2). In this case, a device ID of the receiver mayalso be transmitted. The companion device may determine whether thecompanion device is a receiver that is permitted to make a request forESG data using the received ID of the receiver (t63060).

When a specific service desired by a user or a companion device isidentified according to “atsc.org/esg/service/1”, the GetESGbyServiceIdsaction may be performed using this as an input argument (t63070). Inthis case, authentication information may also be transmitted to areceiver. In some embodiments, the authentication procedure may beconsidered to be redundant and, thus, may be omitted. When theauthentication procedure is omitted, an existing generalGetESGbyServiceIds action may be performed. When the receiver isauthenticated, the receiver may output A_ART_TYPE_ESGData_by_ServiceIdsalong with 200 OK to the companion device (t63080). According to thepresent embodiment, a value of A_ART_TYPE_ESGData_by_ServiceIds may beESG data related to a service identified according to“atsc.org/esg/service/1” (t63110). As illustrated in the drawing, theoutput argument may include a Schedule element withatsc.org/esg/service/1 as a reference value and a Content element aswell as a Service element with atsc.org/esg/service/1 as a service IDvalue. Here, the Schedule element and the Content element may beschedule and content information related to a serviced identifiedaccording to atsc.org/esg/service/1.

The companion device may perform an operation of parsing the receivedESG data and exposing the ESG data through an ESG application using theESG data (t63090). The companion device may perform an operation ofimmediately exposing ESG data or storing the ESG data once in order toexpose the ESG data, like in the aforementioned embodiments.

The illustrated embodiment may be a case in which a user performs thespecific action but, as described above, when the action may be firstperformed (irrespective of whether the specific action is performed)and, then, the user executes the ESG application, etc. at apredetermined time, ESG data that has pre-received and stored throughthe corresponding action may be exposed.

FIG. 68 is a diagram illustrating an operation of transmitting ESG datato a companion device according to a GetService action according to anembodiment of the present invention.

In the case of a service of ESG data, an updating frequency of adding anew service or deleting a service may be low. Accordingly, when ESG dataabout a service is continuously requested/transmitted, unnecessarynetwork overload may be caused. To overcome this, a NumOfServices statevariable, an A_ARG_TYPE_ESGData_Service state variable, and a GetServiceaction may be defined. In addition, another embodiment of theaforementioned GetESGbyServiceIds action may be defined.

The NumOfServices state variable may be a state variable for storing thetotal number of services described by ESG of the receiver. A value ofthe state variable may be referred to configure a service list. Forexample, a value of the state variable may be used to check validationduring configuration of a service list. The state variable may be a typeof an integer.

The A_ARG_TYPE_ESGData_Service state variable may be a state variablefor storing only ESG data corresponding to a Service element of ESG ofthe receiver. The state variable may have a fragment type of a specificform of Markup Language for representing the ESGData state variable. Forexample, when the ESGData state variable is an XML document, the statevariable may have an XML fragment type.

The GetService action may be an action for receiving ESG data related toa service among ESG information items from the receiver by the companiondevice. The companion device may receive ESG data (ESG data items exceptfor Service element) related to a specific service using ESG data(Service elements) received through the action. The companion device maycompare the total number of services indicated by a NumOfServices statevariable and the number of the received Service elements to refer theresult to configure a service list. During this procedure, theaforementioned authentication procedure may be used. That is, theGetService action may be extended form including additional input/outputargument for authentication. In some embodiments, a GetService actionwithout additional variable for authentication may be used.

An input argument of the action may be state variables corresponding tothe aforementioned authentication input argument. An output argument maybe a PrimaryDeviceld state variable, a NumOfServices state variable, oran A_ARG_TYPE_ESGData_Service state variable.

Another embodiment of the aforementioned GetESGbyServiceIds action maybe defined. The GetESGbyServiceIds action according to anotherembodiment may be an action for receiving the remaining ESG data relatedto a specific service using service IDs of a specific service as inputby the companion device. Here, the remaining ESG data may be ESG dataexcept for the corresponding Service element, that is, ESG datacorresponding to Content and Schedule elements related to thecorresponding service. Similarly, the action may also be defined in anextended form including additional variables for the aforementionedauthentication.

The GetService and GetESGbyServiceIds actions may be performed when auser wants to see ESG through the companion device and an ESGapplication, etc. are executed. In this case, ESG data may be receivedas a result of the corresponding action and the received ESG data may beexposed through the ESG application. In some embodiments, when theGetService and GetESGbyServiceIds actions are executed using a periodicpolling method to store ESG data in the companion device and, then, theESG application is executed, the stored ESG data may be exposed to theuser.

According to the present embodiment, the two devices are assumed to bepaired with each other. The companion device is assumed to subscribe tothe aforementioned ESG service.

The receiver may own ESG data (t64010). The ESG data may be stored inthe ESGData state variable. The ESG data stored in ESGData may be ESGdata about two services identified according to “atsc.org/esg/service/1”or “atsc.org/esg/service/2” (t64100). A user may take a specific actionof executing an ESG application (t64020). The specific action may be anoperation that requires ESG data.

The companion device may perform the GetService action to make a requestfor ESG data about a service (t64030). Upon determining that thecompanion and/or app are authenticated (t64040), the receiver may outputthe A_ARG_TYPE_ESGData_Service state variable along with 200 OK to thecompanion device (t64050). Here, the A_ARG_TYPE_ESGData_Service statevariable may include only ESG data about a Service element of ESG dataof the receiver (t64110). The companion device may performauthentication using the received device ID of the receiver to determinewhether the data is reliable information (t64060).

The companion device may perform the GetESGbyServiceIds action to make arequest for the remaining ESG data related to a specific service(t64070). In the present embodiment, a ServiceIdsList input argumentvalue of the GetESGbyServiceIds action may be atsc.org/esg/service/1.Upon determining that the companion and/or app are authenticated, thereceiver may output the A_ARG_TYPE_ESGData_by_ServiceIds state variablealong with 200 OK (t64080). According to the present embdoiemnt, theoutput A_ARG_TYPE_ESGData_by_ServiceIds state variable may be ESG datarelated to a service identified according to atsc.org/esg/service/1(t64120). As illustrated in the drawing, the output argument may includea Schedule element having atsc.org/esg/service/1 as a reference valueand a Content element. The output argument may not include a Serviceelement identified according to atsc.org/esg/service/1.

The companion device may perform an operation of parsing the receivedESG data and exposing the ESG data through an ESG application using theESG data (t64090). The companion device may perform an operation ofimmediately exposing ESG data or storing the ESG data once in order toexpose the ESG data, like in the aforementioned embodiments.

The illustrated embodiment may be a case in which a user performs thespecific action but, as described above, when the action may be firstperformed (irrespective of whether the specific action is performed)and, then, the user executes the ESG application, etc. at apredetermined time, ESG data that has been pre-received and storedthrough the corresponding action may be exposed.

FIG. 69 is a diagram illustrating a procedure of changing a service of abroadcast receiver by a companion device according to a SetChangeChannelaction according to an embodiment of the present invention.

ESG information transmitted to the companion device may be exposed tothe user through a user interface (UI). A service indicated by the ESGmay be checked and selected by a user. In this case, a device to which aservice is actually provided is a receiver and, thus, information forchanging a service needs to be transmitted to the receiver to change aservice. To this end, the A_ARG_TYPE_SelectedServiceId state variableand the SetChangeChannel action may be defined.

The A_ARG_TYPE_SelectedServiceId state variable may be a state variablefor storing a service ID of the service that is selected through ESGdata by a user in a companion device. The state variable may be a stringor a specific URI type.

The SetChangeChannel action may be an action for changing a serviceprovided to a receiver by a companion device. The input argument may bean A_ARG_TYPE_SelectedServiceId state variable. The user may select aspecific service while seeing ESG through the companion device. In thiscase, an ID of a corresponding service may be stored as an inputargument. When the corresponding action is performed, the receiver maychange a channel to a service with a corresponding service ID accordingto a value of the input argument. The output argument may be none.

According to the present embodiment, the two devices are assumed to bepaired with each other. The companion device is assumed to subscribe tothe aforementioned ESG service.

The receiver may own ESG data (t65010). The ESG data may be stored inthe ESGData state variable. The user may take a specific action ofexecuting an ESG application (t65030). The specific action may be anoperation that requires ESG data.

The companion device may make a request for ESG data through theaforementioned GetESGData action and receive ESG data (t65040). The Theillustrated embodiment may be a case in which a user performs thespecific action but, as described above, when the action may be firstperformed (irrespective of whether the specific action is performed)and, then, the user executes the ESG application, etc. at apredetermined time, ESG data that has been pre-received and storedthrough the corresponding action may be exposed.

The companion device may perform an operation of parsing the receivedESG data and exposing the ESG data through an ESG application using theESG data (t65050). The companion device may perform an operation ofimmediately exposing ESG data or storing the ESG data once in order toexpose the ESG data, like in the aforementioned embodiments.

The user may select a service through the UI of the companion devicewhile seeing ESG (t65060). For example, the user may attempt to change acurrent channel to an NBCU channel. The companion device may perform theSetChangeChannel action (t65070). A service ID corresponding to the NBCUchannel may be transmitted to the receiver through the action.

The receiver may change a channel to a corresponding service using thereceived service ID (t65080). The service may be changed to NBCU andprovided to the user (t65090).

FIG. 70 is a diagram illustrating a method of providing a broadcastservice according to an embodiment of the present invention.

The method of providing a broadcast service by a broadcast receiveraccording to an embodiment of the present invention may include paringthe broadcast receiver with a companion device and/or receivingelectronic service guide (ESG).

A network interface unit of the broadcast receiver may be paired withthe companion device (t66010). Here, the network interface unit maycorrespond to a network interface of the aforementioned broadcastreceiver. For pairing, technology such as UPnP may be used buttechnology for pairing may not be limited thereto.

A receiving unit of the broadcast receiver may receive ESG and specificservice guide. Here, the receiving unit may be a broadcast interface ora network interface of the aforementioned broadcast receiver. When ESGis received through a broadcast network, the receiving unit maycorrespond to a broadcast interface and when ESG is received through theInternet, the receiving unit may correspond to a network interface. Thatis, in some embodiments, the network interface unit and the receivingunit may be the same block/module.

According to the present embodiment, ESG may include ESG data about atleast one broadcast service. Here, the ESG data may refer to dataincluded in the ESG or element/attributes in the ESG. The broadcastservice may correspond to the aforementioned service or channel.

The method of providing a broadcast service according to an embodimentof the present invention, the ESG data may be service type information,schedule information, related content information, or related componentinformation of the aforementioned at least one broadcast service. TheESG data may be each of the aforementioned type attributes of theService element, the Schedule element, the Content element, or theComponent element. Here, related content and related components mayrefer to content related to a service described by the ESG and acomponent related thereto.

The method of providing a broadcast service according to an embodimentof the present invention may further include transmitting information onmodified content of the received ESG to the companion device. Theoperation may be performed by the aforementioned network interface unit.Here, the information on modified content may include added, modified,or deleted ESG data of the received ESG compared with pre-stored ESGdata. Here, the information on modified content may be theaforementioned LastChangedESGData state variable. The added, modified,and deleted ESG data may be Addition, Modification, and Deletionelements, respectively.

The method of providing a broadcast service according to an embodimentof the present invention may further include transmitting an ID list ofbroadcast services included in the received ESG to the companion device,receiving a request for ESG data related to specific broadcast servicesidentified according to at least one ID of an ID list from the companiondevice, and transmitting ESG data related to the requested specificbroadcast service to the companion device. The service ID list may betransmitted through the aforementioned GetServiceIds action. The requestand transmission of the ESG data according to an ID may be performedthrough the aforementioned GetESGbyServiceIds action.

The method of providing a broadcast service according to an embodimentof the present invention may further include receiving a request for anID of a currently watched broadcast service from the companion deviceand transmitting the ID of the currently watched broadcast service tothe companion device, receiving a request for ESG data related to thecurrently watched broadcast service, and transmitting the requested ESGdata related to the currently watched broadcast service to the companiondevice. The ID of the currently watched service may be transmittedthrough the aforementioned GetCurrentServiceId action. The request andtransmission of the ESG data according to an ID may be performed throughthe aforementioned GetESGbyServiceIds action.

The method of providing a broadcast service according to an embodimentof the present invention may further include receiving a target value ofa search field indicating a specific field of ESG data and a targetvalue of a specific field from the companion device, selecting ESG datahaving the target value of the specific field indicated by the searchfield by a control unit, and transmitting the selected ESG data to thecompanion device. The search field and the target value of the specificfield may correspond to the aforementioned A_ART_TYPE_SearchField statevariable and A_ART_TYPE_TargetValue state variable, respectively.Selection and transmission of ESG data may be performed through theaforementioned SearchESG action. Here, the control unit may correspondto a control unit of a main physical device of the aforementionedbroadcast receiver.

The method of providing a broadcast service according to an embodimentof the present invention may further include receiving authenticationinformation of a companion device from a companion device, theauthentication information including device ID information of thecompanion device, checking whether the companion device is authenticatedusing the authentication information by an authentication module, andwhen the companion device is checked to be authenticated, transmittingdevice ID information of the broadcast receiver to the companion device.Here, the authentication information may correspond to theaforementioned CompanionDeviceId, CompanionDeviceAppId, and/orCompanionDeviceAppVersion state variables. The device ID of thebroadcast receiver may correspond to the aforementioned PrimaryDeviceldstate variable. An operation of transmitting the authenticationinformation, checking authentication, and transmitting a receiver deviceID may be performed through the aforementioned DoAuthenticationForESGaction. Here, the authentication module may be a block/module that ispositioned inside/outside the broadcast receiver and performs theaforementioned operations related to authentication. In someembodiments, the authentication module may be integrated with theaforementioned control or network interface.

In the method of providing a broadcast service according to anembodiment of the present invention, the transmitting of the ID list tothe companion device may include receiving a request for the ID listfrom the companion device, the request for the ID list includingauthentication information of the companion device, checking whether thecompanion device is authenticated using the authentication informationby an authentication module; and when the companion device is checked tobe authenticated, transmitting the ID list and device ID information ofa broadcast receiver to the companion device. The present embodiment maybe obtained by extending the aforementioned embodiment of transmissionof ESG through a service ID list to the case in which the GetServiceIdsaction performs authentication.

The method of providing a broadcast service according to an embodimentof the present invention may further include receiving a request forchange in a currently watched broadcast service from the companiondevice, the request for change in the currently watched broadcastservice being based on the received ESG data, and changing a broadcastservice watched in a broadcast receiver according to the request forchange in the broadcast service by a control unit. The receiving of therequest for broadcast and the changing of the service based on therequest may be performed by the aforementioned SetChangeChannel action.

The aforementioned method of providing a broadcast service may bedescribed in terms of a companion device. The present invention alsoincludes the case in which the aforementioned embodiments are performedin terms of the companion device. For example, the companion device mayreceive information of modified content of ESG or may request an ID listof a service and receive related ESG data using the ID. The companiondevice may make a request for an ID of a currently watched service andreceive related ESG data using the ID. The companion device may transmita search field indicting a specific field and a specific value to areceiver and receive matched ESG data and may transmit authenticationinformation to the receiver and perform authentication. The companiondevice may make a request for change in a currently watched service.Communication with the receiver may be performed by the aforementionednetwork interface inside/outside the companion device. Overalloperations such as a search field related operation, a service changerequest related operation, and an ESG data related processing operationmay be performed by the aforementioned control unit inside/outside thecompanion device. The companion device may include an authenticationmodule that performs an authentication related operation.

Each of the aforementioned operations may be omitted or replaced withanother operation with the same or similar function.

FIG. 71 is a diagram of a broadcast receiver according to an embodimentof the present invention.

The broadcast receiver according to an embodiment of the presentinvention may include a network interface unit and/or a receiving unit.The broadcast receiver according to another embodiment of the presentinvention may further include a control unit and/or an authenticationmodule. Each block, module, and unit are the same as the aforementioneddescription.

According to an embodiment of the present invention, the broadcastreceiver and module/block/units therein may perform embodiments ofproviding the aforementioned method of providing a broadcast service bya broadcast receiver.

According to an embodiment of the present invention, the companiondevice may include a network interface unit and/or a receiving unit.According to another embodiment of the present invention, the companiondevice may further include a control unit and/or an authenticationmodule. Each block, module, and unit are the same as the aforementioneddescription.

According to an embodiment of the present invention, the companiondevice and module/block/units therein may perform the aforementionedembodiments of providing a broadcast service by the companion device.

The aforementioned broadcast receiver, the block/module/unit, etc. inthe companion device may be processors that perform consecutiveprocedures stored in a memory or, in some embodiments, may be hardwareelements positioned inside/outside a device.

Each of the aforementioned block/module/units may be omitted or replacedwith another block/module with the same or similar function.

FIG. 72 illustrates a UPnP based PD-CD architecture according to anembodiment of the present invention.

A main physical device may correspond to a TV receiver (broadcastreception apparatus, PD). A companion physical device may correspond tothe aforementioned CD (companion device). The two devices are physicaldevices and may refer to a PD or a CD.

In the present embodiment, the main physical device may include a maindevice. Here, the main device may correspond to a controlled devicedefined in UPnP. Hereinafter, the main device will be called acontrolled device for convenience of description.

In the present embodiment, the companion physical device may include amain control point. Here, the main control point may correspond to acontrol point defined in UPnP. The main control point may refer to acontrol point that communicates with a main controlled device.

The controlled device may be positioned in the TV receiver in the UPnParchitecture and perform various operations. When the TV receiver joinsa home network, the controlled device can multicast an advertisementmessage or deliver a UPnP service description provided by a PD to thecontrol point. In addition, the controlled device may deliver a statevariable to the control point in an eventing manner or deliverinformation to the control point when the control point requests aspecific operation according to an action method. A PC such as the TVreceiver may be called a controlled device.

The controlled device may provide an Application Management Serviceand/or a Connection Establishment Service. These services may be UPnPservices provided by the controlled device. The application managementservice may refer to services related to management of applicationsexecuted in the controlled device and the control point. App-to-appcommunication or services for delivering specific information to anapplication may correspond to the application management service. In theillustrated embodiment, applications App#1 and App#2 in the PD maycommunicate with applications App#1 and App#3 in the CD according to theapplication management service.

The connection establishment service may be a service related toestablishment and management of connection between the controlled deviceand the control point. A discovery process between the controlled deviceand the control point may conform to a discovery process defined inUPnP.

First, when a PD joins a home network, the PD can multicast a discoverymessage for advertising the PD. When a CD joins the home network later,the CD can multicast a search message for arbitrary PDs. A PD that hasreceived the search message may unicast a response message to the CD.The advertising message and the search message may be exchangedirrespective of home network join time or order of the PD and the CD andmay be periodically exchanged.

Upon reception of a response message to the advertising message or thesearch message of the PD, the CD may send an HTTP GET request message torequest information about a UPnP service provided by the PD. The PD maydeliver description information about services to the CD in response tothe request. Then, the CD can subscribe to a service of the PD. The CDcan obtain desired information using an action, transmit information orreceive information in an eventing manner.

The main device and the main control point may be called a screen deviceand a screen control device according to an embodiment.

FIG. 73 illustrates a UPnP based PD-CD architecture according to anotherembodiment of the present invention.

In the present embodiment, a main physical device PD may include a maincontrolled device and/or a companion control point. In addition, acompanion physical device CD may include a main control point and/or acompanion control device.

In general, operations and roles of a controlled device and a controlpoint are asymmetrical in a UPnP architecture. That is, an operationthat can be performed by the control device may not be performed by thecontrol point.

To compensate for this, the companion physical device CD may include acompanion controlled device in the same manner as the main physicaldevice PD includes a main controlled device. The main physical devicemay have a companion control point corresponding to each controlleddevice and the companion physical device may have a main control point.The main controlled device may communicate with the main control pointand the companion controlled device may communicate with the companioncontrol point.

The companion controlled device and the companion control point mayexchange a discovery message and perform operations such asevents/actions. Accordingly, the CD may play a leading role incommunication. However, the companion controlled device and thecompanion control point may have different operations, roles and rightsfrom the main controlled device/control point. Specific operations orthe scope of rights may be set by designer.

The companion controlled device and the companion control point may becalled a screen (controlled) device and a screen control point accordingto an embodiment.

FIG. 74 illustrates a UPnP based PD-CD architecture according to anotherembodiment of the present invention.

In the present embodiment, a main physical device PD may include a maincontrolled device and/or a main control point. In addition, a companionphysical device CD may include a main control point and/or a maincontrolled device.

As described above, the PD and the CD may perform asymmetricaloperations in a UPnP architecture. To solve this, an architecture inwhich the PD and the CD further includes a pair of a main control pointand a main controlled device in addition to the main controlled deviceand the main control point, respectively, may be configured. In thiscase, both the PD and the CD can include the equivalent main controlleddevice/the control point, distinguished from the aforementionedembodiment in which the companion controlled device/control pointperform different operations from the main controlled device/controlpoint. Accordingly, an architecture can be configured in such a mannerthat the TV receiver and the companion physical device have equalcommunication rights.

FIG. 75 illustrates interactions in a UPnP based PD-CD architectureaccording to an embodiment of the present invention.

FIG. 75 sequentially illustrates embodiments of the aforementioned UPnPbased PD-CD architectures. The first embodiment t408010 may be anembodiment in which the aforementioned PD includes a controlled deviceand the CD includes a control point. The second embodiment t408020 maybe an embodiment in which the aforementioned PD includes a maincontrolled device and a companion control point and the CD includes amain control point and a companion controlled device. The thirdembodiment t408030 may be an embodiment in which the aforementioned PDincludes a main controlled device and a main control point and the CDincludes a main control point and a main controlled device.

In the first embodiment t408010, the controlled device can deliverinformation such as a state variable to the control point through UPnPeventing. Simultaneously, the control point can request information or aspecific operation from the controlled device through a UPnP action.This may be the most fundamental architecture.

In the second embodiment t408020, the main controlled device cancommunicate with the main control point and the companion controlleddevice can communicate with the companion control point. The maincontrolled device can deliver information such as a state variable tothe main control point through UPnP eventing. Simultaneously, the maincontrol point can request information or a specific operation from themain controlled device through a UPnP action. In addition, the companioncontrolled device can deliver information such as a state variable tothe companion control point through UPnP eventing. Simultaneously, thecompanion control point can request information or a specific operationfrom the companion controlled device through a UPnP action. As describedabove, the companion controlled device and the companion control pointmay have different operations, roles and rights from the main controlleddevice/control point.

In the third embodiment t408030, the main controlled devices of the PDand the CD can communicate with main control points correspondingthereto. The main controlled devices can deliver information such as astate variable to the main control points through UPnP eventing.Simultaneously, the main control points can request information or aspecific operation from the main controlled devices through a UPnPaction.

FIG. 76 illustrates a Websocket based PD-CD architecture according to anembodiment of the present invention.

In the Websocket based architecture, communication can be performedbetween a PD and an application executed in a CD. In the Websocket basedarchitecture, the PD may include a Websocket server and the CD mayinclude applications. Here, applications of the CD may be calledWebsocket clients.

The Websocket server in the PD may have endpoints with respect tooperations/functions provided by the PD. The endpoints may be connectedto applications of the CD to deliver an ESG or media timeline andperform communication between an application of the PD and anapplication of the CD.

First, a discovery process may be performed between the PD and anapplication executed in the CD. The discovery process will be describedbelow. In this process, information about the endpoints of the Websocketserver may be delivered to the application of the CD.

For each endpoint, the application of the CD and the Websocket servercan perform a handshake process. When the application of the CD requestshandshake opening, the Websocket server can send a response to therequest. Accordingly, the Websocket server and the application of the CDcan be connected through an endpoint.

In the Websocket architecture, when the Websocket server and theapplication of the CD are connected through the endpoint, informationcan be transmitted through the endpoint. Messages can be freely relayedbetween applications of the PD and the CD.

When disconnection is required, the application of the CD can requestdisconnection for the endpoint (Disconnect Request). The Websocketserver sends a response to the request (Disconnect Response) andconnection with the endpoint can be terminated. Disconnection may beperformed by the PD first and may be automatically performed in varioussituations.

The aforementioned process may be a process of interacting with a singleWebsocket endpoint. When there are multiple endpoints, theaforementioned process can be equally performed for the endpoints toactivate desired endpoints. This process may be performed for multipleendpoints simultaneously or sequentially.

In the present embodiment, the Websocket server may have endpoints forprovided functions, respectively. That is, a single endpoint can beprovided to a single function.

Such endpoints may include a service/content identification endpoint, anESG information endpoint, a service/show/segment data endpoint, a mediatimeline endpoint, a media playback state endpoint, an EAS endpointand/or an app-to-app endpoint.

The service/content identification endpoint may execute a function ofdelivering information for identifying a service/content that is beingplayed or will be played in a PD. An application of a CD can receive theinformation through this endpoint.

The ESG information endpoint may be used for a CD to receive an ESG. Anapplication of the CD can receive the ESG through this endpoint. Theservice/show/segment data endpoint may receive various types of dataabout services.

The media timeline endpoint may deliver the current time and media timeinformation of a currently played service/content. The aforementionedservice time information may be delivered through this endpoint. Themedia playback state endpoint may deliver information related topresentation of a currently played service/content. The informationrelated to presentation may refer to information indicating whether acurrently played service/content is played at normal speed,fast-forwarded at 3× or reversed. The aforementioned playback stateinformation may be delivered to an application of the CD through thisendpoint.

The EAS endpoint may deliver EAS information to the CD. When the EASinformation is delivered to a TV receiver, it is possible to signal adangerous situation more efficiently by delivering the EAS informationto the CD. The app-to-app end point may be an endpoint for communicationbetween an application executed in a PD and an application executed in aCD. The application of the PD and the application of the CD can exchangeinformation by transmitting/receiving messages using this endpoint.

Since each endpoint is provided for each function, an application of theCD can access an endpoint to perform a connection process and obtaindesired information to communicate with an application of the PD throughthe endpoint.

Hereinafter, this architecture may be referred to as Websocket basedarchitecture embodiment #1 for convenience of description. Thisembodiment can be combined with various embodiments based on UPnP andHTTP as well as other Websocket based architectures.

FIG. 77 illustrates a Websocket based PD-CD architecture according toanother embodiment of the present invention.

In the present embodiment, an endpoint may not be provided to eachfunction. In the present embodiment, a Websocket server of a PD providesa single endpoint which can execute all the aforementioned functions.This endpoint may be called a companion endpoint. Other components ofthe Websocket architecture may be the same as the aforementionedembodiment.

The aforementioned endpoint may execute all functions executed bymultiple endpoints in the aforementioned embodiment. That is, thisendpoint can execute the functions executed by the aforementionedservice/content identification endpoint, the ESG information endpoint,the service/show/segment data endpoint, etc. Accordingly, an applicationof the CD can perform operations such as receiving an ESG, receivingmedia time information and communicating with an application of the PDonly by connecting to the endpoint. In this case, however, a functionfor which a message is exchanged between the application of the CD andthe Websocket server needs to be identified. Accordingly, the messagemay include more specific information or may be extended.

Since the companion endpoint executes all functions, all the functionscan be executed when connection to the endpoint is established. Aprocess of connecting to the endpoint may be the same as theaforementioned process of connecting to a normal endpoint. In this case,connection to the endpoint cannot be partially terminated even when acertain function need not be accessed because there is a singleendpoint. On the contrary, even when only one function is required,connection to the companion endpoint must be established.

Hereinafter, this architecture may be referred to as Websocket basedarchitecture embodiment #2 for convenience of description. Thisembodiment can be combined with various embodiments based on UPnP andHTTP as well as other Websocket based architectures.

FIG. 78 illustrates a Websocket based PD-CD architecture according toanother embodiment of the present invention.

In the present embodiment, n endpoints are provided and can execute mfunctions. Here, n may be equal to or less than m, and n and m may beintegers. That is, a plurality of (n) endpoints each of which canexecute one or more functions can be provided.

In the illustrated embodiment, an endpoint that executes aservice/content identification function, an ESG delivery function andthe like may be provided as a companion endpoint and an endpoint thatexecutes an app-to-app function may be provided as a separate“app-to-app endpoint”.

The architecture of the present embodiment may be regarded as acombination of the aforementioned Websocket based architectures #1 and#2. Various architectures can be configured depending on values of n andm. Various numbers of endpoints may be provided and each endpoint mayprovide various numbers of functions.

The above-described connection to and disconnection from endpoints mayneed to be performed for each endpoint. That is, the process may need tobe performed n times for n endpoints.

Hereinafter, this architecture may be referred to as Websocket basedarchitecture embodiment #3 for convenience of description. Thisembodiment can be combined with various embodiments based on UPnP andHTTP as well as other Websocket based architectures.

FIG. 79 illustrates app-to-app communication in a Websocket based PD-CDarchitecture according to an embodiment of the present invention.

App-to-app communication may be performed between an applicationexecuted in the PD and an application executed in the CD. In a Websocketbased architecture, applications can communicate through a Websocketserver. Here, the aforementioned app-to-app endpoint can be used.Alternatively, an endpoint executing the app-to-app communicationfunction and other functions may be used according to an embodiment.

The application of the CD can connect to the app-to-app communicationendpoint of the Websocket server through the aforementioned process.Applications executed in the PD correspond to Websocket clients, and theapplication of the PD can connect to the app-to-app communicationendpoint of the Websocket server. The Websocket server can connectmatching connection requests from among received connection requests toenable message exchange.

When the applications of the PD and the CD are connected, theapplications can exchange messages through the Websocket server. Themessages can be delivered bidirectionally. The Websocket server canrelay a message sent from one application to the other application.

FIG. 80 illustrates an HTTP based PD-CD architecture according to anembodiment of the present invention.

In the HTTP based architecture, communication can be performed between aPD and an application executed in a CD. In the HTTP based architecture,the PD may include an HTTP server and the CD may include applications.Here, applications of the CD may be called HTTP clients.

The HTTP server included in the PD may be a server for performingvarious operations/functions. To access each function of the server, aservice URL for a corresponding service may be needed. An application ofthe CD may send a request to the corresponding service URL to receivedesired information.

First, a discovery process may be performed between the PD and theapplication executed in the CD. In this process, information about URLsof the HTTP server may be delivered to the application of the CD. HTTPclients of the CD may access desired URLs using the delivered URLinformation to receive desired information.

In the present embodiment, the HTTP server may have different URLs forfunctions. That is, a single URL can be provided for a single function.

Services provided through such service URLs may be similar to functionsprovided by the aforementioned Websocket server. For example, when theapplication of the CD accesses a service/content identification serviceURL, the application can receive information for identifying aservice/content that is being played or will be played in the PD. Thatis, the application of the CD can send a request for service/contentidentification information to the service/content identification serviceURL and the HTTP server of the PD can deliver the requested informationto the application of the CD. An ESG information service, a mediatimeline service and the like corresponding to the functions provided bythe aforementioned ESG information endpoint, media timeline endpoint andthe like can be defined. The application of the CD can receive desiredinformation by sending a request to each service URL.

Since service URLs are respectively provided to services, theapplication of the CD needs to know information about each URL and toaccess a desired URL to obtain desired information or communicate withan application of the PD.

Hereinafter, this architecture may be referred to as HTTP basedarchitecture embodiment #1 for convenience of description. Thisembodiment can be combined with various embodiments based on UPnP andHTTP as well as other HTTP based architectures.

FIG. 81 illustrates an HTTP based PD-CD architecture according toanother embodiment of the present invention.

In the present embodiment, service URLs may not be provided torespective services. In the present embodiment, an HTTP server of a PDprovides a single service URL through which all the aforementionedfunctions can be executed. This service URL may be called a companionservice URL. Other components of the HTTP architecture may be the sameas the aforementioned embodiment.

The single service URL may be a service URL through which all functionsexecuted through multiple service URLs in the aforementioned embodimentcan be executed. That is, this service URL can execute the functionsexecuted by the aforementioned service/content identification serviceURL, ESG information service URL, the service/show/segment data serviceURL, etc. Accordingly, an application of the CD can receive an ESG ormedia time information only by sending a request to the service URL.

In this case, when a request is sent to the HTTP server, the requestmessage may be extended in such a manner that a new variable is attachedto the query term. This is because it is necessary to identifyinformation that the application of the CD wants to receive by sending arequest to the companion service URL. The HTTP server can analyze therequest and deliver the information that the application of the CDdesires.

Hereinafter, this architecture may be referred to as HTTP basedarchitecture embodiment #2 for convenience of description. Thisembodiment can be combined with various embodiments based on UPnP andHTTP as well as other HTTP based architectures.

FIG. 82 illustrates a Websocket & HTTP based PD-CD architectureaccording to an embodiment of the present invention.

The aforementioned UPnP based architectures, Websocket basedarchitectures and HTTP based architectures may be combined. For example,a PD may simultaneously have an HTTP server and a Websocket server.According to an embodiment, the PD may have the HTTP server and theWebsocket server and serve as a controlled device in a UPnParchitecture.

In addition, a combined UPnP architecture may be one of theaforementioned first, second and third UPnP architecture embodiments #1,#2 and #3. A combined Websocket architecture may be one of theaforementioned first, second and third Websocket architectureembodiments #1, #2 and #3, and a combined HTTP architecture may be oneof the aforementioned first, second and third HTTP architectureembodiments #1 and #2.

In the present embodiment, the PD simultaneously has the HTTP server andthe Websocket server, HTTP based architecture #2 can be used as an HTTParchitecture, and Websocket based architecture #3 can be used as aWebsocket architecture. That is, in the HTTP server, a single serviceURL address can execute a plurality of functions. The Websocket serverprovides n endpoints that can execute a plurality of functions.Specifically, two endpoints are provided, one endpoint serves as anendpoint for app-to-app communication, and the other endpoint serves asan endpoint executing all other functions in the present embodiment.

Although only the above-described embodiments are described herein, thetechnical scope of the present invention includes all other combinationsas embodiments. Various architectures can be designed according to suchcombinations and selected and used according to designer.

In the architecture as in the present embodiment, functions may bedivided and executed by the HTTP server and the Websocket server. Thatis, the HTTP server may be used to execute specific functions and asingle HTTP service URL may be used to receive requests for executingthe functions. In addition, the Websocket server may provide endpointsfor executing other functions.

Such function division may be performed depending on characteristics ofcorresponding functions. The HTTP may be used for asynchronouscommunication whereas the Websocket may be used for synchronouscommunication.

According to an embodiment, the ESG information delivery function, theservice/show/segment data delivery function and the like may beperformed by the HTTP server. That is, information such as an ESG orservice data can be acquired by sending a request to a service URL ofthe HTTP server.

In addition, the service/content identification function, the mediaplayback state function, the app-to-app communication function and thelike may be performed by the Websocket. The Websocket server may providethe companion endpoint for executing the media playback state functionand the app-to-app endpoint for executing the app-to-app communicationfunction.

According to an embodiment, the media timeline function may be executedby the HTTP and/or Websocket. The media timeline function may beprovided by both the HTTP and the Websocket or provided by one of theHTTP and the Websocket. The EAS information delivery function may beexecuted by the Websocket or a multicast sender in the PD. When themulticast sender is used, the multicast sender in the PD can multicastEAS information to devices in a multicast group.

FIG. 83 illustrates formats of messages used for discovery of a PD(Primary Device) according to an embodiment of the present invention.

The PD can be discovered by a CD or an application executed in the CD.In this process, an SSDP (Simple Service Discovery Protocol) may beused. The PD may have an ST (Search Target) value for identifying atechnical standard to which the PD conforms. For example, the PD can useurn:atsc:device:atsccompani on:3 or urn:atsc:service:atsccompanion:3 asa device type or service type thereof. These values can be used in adiscovery process through ST matching.

For a discovery process, the PD may advertise itself to CDs.Alternatively, a CD may discover the PD through search.

First, when the PD advertises itself to CDs, the PD can multicast adiscovery message. This discovery message may be transmitted through aNOTIFY method. The discovery message for advertising of the PD may be asillustrated in embodiment t413010.

When a CD discovers the PD through search, the CD or an applicationexecuted in the CD can multicast a discovery message. This discoverymessage may be transmitted through an M-SEARCH method. The discoverymessage for searching of the CD may be as illustrated in embodimentt413020.

The application of the CD can discover PDs conforming to a specifictechnical standard using the ST value. The PD can receive theaforementioned search message. When the ST value of the PD matches theST value of the message, the PD can send a response to the applicationof the CD which has sent the message (200 OK). This response message maybe as illustrated embodiment t413030.

The illustrated message formats are merely embodiments of the presentinvention and parameters included in the messages may have differentvalues according to embodiments.

The discovery process described herein can be applied to HTTParchitectures as well as Websocket architectures.

FIG. 84 illustrates a process for discovering a Websocket endpoint or anHTTP service URL using a DDD (Device Description Document) according toan embodiment of the present invention.

As described above, a PD may multicast a discovery message foradvertising the PD or transmit a response message to a received M-SEARCHmessage to a CD. An application of the CD may obtain a URL from aLOCATION header of the multicast discovery message or the responsemessage to the M-SEARCH message. The URL may be a URL through which aDDD (Device Description Document) can be acquired. The application ofthe CD may acquire the DDD using the URL to obtain device descriptioninformation.

Specifically, the PD may multicast a discovery message for advertisingthe PD through the NOTIFY method as described above. In this process,URL information for acquiring a DDD may be delivered to the applicationexecuted in the CD. Alternatively, when the application of the CDmulticasts a discovery method for searching using the M-SEARCH method,the PD may send a response message thereto to the CD. In this process,the URL information for acquiring the DDD may also be delivered to theapplication executed in the CD (t417010).

Then, the application of the CD may send a request for the DDD to theacquired URL using HTTP GET. The PD may deliver the DDD to theapplication of the CD using a response message (t417020). The body ofthe response message may include the DDD.

Addresses of Websocket endpoints may be provided to the application ofthe CD through the DDD. According to an embodiment, addresses of serviceURLs of an HTTP architecture may be provided to the application of theCD through the DDD. When an architecture in which two or more protocolsare combined is used, addresses of Websocket endpoints and/or addressesof service URLs of the HTTP may be provided to the application.

FIG. 85 illustrates a DDD request message and a DDD format in a processfor discovering a Websocket endpoint or an HTTP service URL using a DDDaccording to an embodiment of the present invention.

As described above, an application of a CD may request a DDD using HTTPGET. Here, the GET message may have a format as illustrated inembodiment t418010. A DDD request message using GET may be transmittedto a URL of a DDD acquired from a PD. In addition, host information ofan IP address/port of the description may be used. Furthermore, alanguage preferred by a control point may be used.

As described above, a response message to the DDD request message may bereturned. The body of the response message may include the DDD. The DDDmay have a format as illustrated in embodiment t418020.

The DDD may include specification version information, base URLinformation, device related information, etc. The specification versioninformation specVersion can indicate version information of acorresponding DDD specification as a major version/minor version. Thebase URL information can include base URL information that can be usedfor all related URLs delivered by the DDD.

The device related information can include type information of a devicedescribed by the DDD, short device name information readable by a user(friendlyName), manufacture information of a corresponding device,service list information, etc.

The service list information can include service type informationindicating the type of each service provided by the correspondingdevice, service ID information indicating the ID of the service, servicedescription URL information indicating a URL related to servicedescription, control URL information used for control of thecorresponding service and/or URL information used for eventing of thecorresponding service.

The illustrated formats are merely embodiments of the present inventionand structures thereof, elements included therein and values of theelements may be varied according to embodiments.

FIG. 86 illustrates DDD formats in a process for discovering a Websocketendpoint or an HTTP service URL using a DDD according to an embodimentof the present invention.

As described above, addresses of Websocket endpoints or addresses ofHTTP service URLs may be delivered to an application of a CD through DDDdelivery. The application of the CD may connect to a Websocket endpointor send a request to a service URL using the addresses.

In the aforementioned Websocket based architecture embodiment #1, theDDD format according to the illustrated embodiment t419010 or the DDDformat according to the embodiment t419020 may be used.

In the illustrated embodiment t419010, device information of the DDD mayinclude address information of various Websocket endpoints in additionto the device type information. As shown, address information aboutendpoints such as the service/content identification endpoint and theESG information endpoint is included in the device information of theDDD. Since the DDD format is used in Websocket based architectureembodiment #1, the pieces of address information about the endpoints maybe arranged. The DDD format according to illustrated embodiment t419020may also include address information about various Websocket endpoints.In this case, the address information about the endpoints may beincluded in the service information of the DDD.

While the address information is positioned below the device informationand the service information in the present embodiment, the addressinformation may be arranged at other positions in the DDD. In theillustrated embodiment, other elements of the aforementioned DDD areomitted. Other elements may be configured according to variousembodiments.

The DDD formats according to the illustrated embodiments t419010 andt419020 may be used in the aforementioned HTTP based architectureembodiment #1. In this case, the address information of the Websocketendpoints can be replaced by URL address information of service URLs.Accordingly, element names may be changed. Similarly, since the DDDformats are used in HTTP based architecture embodiment #1, the pieces ofaddress information of the service URLs may be arranged.

Addresses of Websocket endpoints may be configured in the form ofws://localhost:8030/E S GInformati on, ws://localhost:8030/Data andws://localhost:8030/MediaTimeline. Addresses of HTTP service URLs may beconfigured in the form of http://192.1681.4:8080/serviceidentificationand http://localhost:8030/ES GInformation.

FIG. 87 illustrates DDD formats in a process for discovering a Websocketendpoint or an HTTP service URL using a DDD according to anotherembodiment of the present invention.

In the aforementioned Websocket based architecture embodiment #2, a DDDformat according to the illustrated embodiment t420010 or a DDD formataccording to the illustrated embodiment t420020 may be used.

In the illustrated embodiment t420010, the device information of the DDDmay include addresses of Websocket endpoints in addition to the devicetype information. Since the DDD format is used in Websocket basedarchitecture embodiment #2, only address information about a singlecompanion endpoint may be included therein. The DDD format according tothe illustrated embodiment t420020 may also include only addressinformation about a single companion endpoint. In this case, the addressinformation of the corresponding endpoint can be included in the serviceinformation of the DDD.

The DDD formats according to the illustrated embodiments t420010 andt420020 may be used in the aforementioned HTTP based architectureembodiment #2. In this case, the address information of the Websocketcompanion endpoint can be replaced by URL address information of acompanion service URL. Accordingly, element names may be changed.Similarly, since the DDD formats are used in HTTP based architectureembodiment #2, only address information of a single service URL can beincluded therein.

In the aforementioned Websocket based architecture embodiment #3, theDDD format according to the illustrated embodiment t420030 or the DDDformat according to the illustrated embodiment t420040 may be used.

In the illustrated embodiment t420030, the device information of the DDDmay include address information of n Websocket endpoints in addition tothe device type information. For example, the device information mayinclude address information of a companion endpoint that executes theservice/content identification function, the ESG information deliveryfunction, etc. and address information of the app-to-app communicationendpoint. The DDD format according to the illustrated embodiment t420040may also include address information of n Websocket endpoints. In thiscase, address information of corresponding endpoints can be included inthe service information of the DDD.

While the address information is positioned below the device informationand the service information in the present embodiment, the addressinformation may be arranged at other positions in the DDD. In theillustrated embodiment, other elements of the aforementioned DDD areomitted. Other elements may be configured according to variousembodiments.

FIG. 88 illustrates a process for discovering a Websocket endpoint or anHTTP service URL using a response header to a DDD request according toan embodiment of the present invention.

As described above, a PD may multicast a discovery message foradvertising the PD or transmit a response message to a received M-SEARCHmessage to a CD. An application of the CD may obtain a URL from aLOCATION header of the multicast discovery message or the responsemessage to the M-SEARCH message. This process may be the same as theprocess in the aforementioned embodiment.

The URL may be a URL through which a DDD can be acquired, and theapplication of the CD may send a message for requesting the DDD to theURL using HTTP GET. The DDD is delivered through the body of a responsemessage to the request and thus the application of the CD can obtaindevice description information (t421020).

In the above-described embodiment, addresses of Websocket endpoints oraddress information of HTTP service URLs are delivered through the DDDof the response message. In the present embodiment, the addressinformation may be delivered through the header of the response message.In this case, the body of the response message may include noinformation or may include the DDD.

FIG. 89 illustrates a format of a response header in a process fordiscovering a Websocket endpoint or an HTTP service URL using a responseheader to a DDD request according to an embodiment of the presentinvention.

As described above, an application of a CD may request a DDD using HTTPGET. Here, the GET message may have a format as illustrated inembodiment t422010. A DDD request message using GET may be transmittedto a URL of a DDD acquired from a PD. Furthermore, host information ofan IP address/port of description may be used. In addition, a languagepreferred by a control point may be used. The GET message may be thesame as the message in the aforementioned embodiment.

As described above, a response message to the DDD request message may bereturned. Address information may be delivered through the header of theresponse message.

In the aforementioned Websocket based architecture embodiment #1, aresponse header format according to the illustrated embodiment t422020may be used. The response header according to the embodiment can includeaddress information of various Websocket endpoints in addition to basic200 OK message information. As shown, address information aboutendpoints such as the service/content identification endpoint and theESG information endpoint may be included in the response header. Sincethe response header format is used in Websocket based architectureembodiment #1, the pieces of address information about the endpoints maybe arranged. Here, the structure and form in which address informationis included in the response header may be configured in various mannersaccording to embodiments.

The response header format according to the illustrated embodimentt422020 may be used in the aforementioned HTTP based architectureembodiment #1. In this case, the address information of the Websocketendpoints can be replaced by URL address information of service URLs.Accordingly, element names may be changed. Similarly, since the responseheader format is used in HTTP based architecture embodiment #1, thepieces of address information of the service URLs may be arranged.

In the aforementioned Websocket based architecture embodiment #2, aresponse header format according to the illustrated embodiment t422030may be used. The response header according to the embodiment can includeaddress information of a Websocket endpoint in addition to basic 200 OKmessage information. Since the response header format is used inWebsocket based architecture embodiment #2, only address informationabout a companion endpoint can be included therein. Here, the structureand form in which the address information is included in the responseheader may be configured in various manners according to embodiments.

The response header format according to the illustrated embodimentt422030 may be used in the aforementioned HTTP based architectureembodiment #2. In this case, the address information of the Websocketcompanion endpoint can be replaced by address information of a companionservice URL. Accordingly, element names may be changed. Similarly, sincethe response header format is used in HTTP based architecture embodiment#2, only the address information of the companion service URL may beincluded therein.

In the aforementioned Websocket based architecture embodiment #3, aresponse header format according to the illustrated embodiment t422040may be used. The response header according to the embodiment can includeaddress information of n Websocket endpoints in addition to basic 200 OKmessage information. For example, address information of a companionendpoint that executes the service/content identification function, theESG information delivery function, etc. and address information of theapp-to-app communication endpoint may be included in the responseheader. Here, the structure and form in which address information isincluded in the response header may be configured in various mannersaccording to embodiments.

FIG. 90 illustrates a process for discovering a Websocket endpoint or anHTTP service URL using a URL of a response header to a DDD requestaccording to an embodiment of the present invention.

As described above, a PD may multicast a discovery message foradvertising the PD or transmit a response message to a received M-SEARCHmessage to a CD. An application of the CD may obtain a URL from aLOCATION header of the multicast discovery message or the responsemessage to the M-SEARCH message. The URL may be a URL through which aDDD can be acquired, and the application of the CD may send an HTTP GETrequest to the URL. The processes t42310 and t42320 may be the same asthe forementioned embodiment.

Here, a response message may be received as a response to the HTTP GETrequest. In the aforementioned embodiment, address information has beendelivered through a DDD included in the body of the response message orthe response message header. In the present embodiment, a URL throughwhich address information can be acquired may be delivered through theresponse message header. In this case, the body of the response messagemay include no information and or may include a DDD (t423020).

The application of the CD may request address information by sending theHTTP GET request to the delivered URL for the address information. ThePD may send a response message to the application of the CD. The addressinformation can be delivered to the CD through the response message(t423030). The address information may be delivered through the body ofthe response message. According to an embodiment, the addressinformation may be delivered through the header of the response message.

FIG. 91 illustrates a GET request and response message formats accordingthereto in a process for discovering a Websocket endpoint or an HTTPservice URL using a URL of a response header to a DDD request accordingto an embodiment of the present invention.

As described above, an application of a CD may request a DDD using HTTPGET. Here, the GET message may have a format as illustrated inembodiment t424010. A DDD request message using GET may be transmittedto a URL of a DDD acquired from a PD. Furthermore, host information ofan IP address/port of description may be used. The GET message may bethe same as the message in the aforementioned embodiment.

A response message may be received in response to the HTTP GET request.The response message may have a format as shown in embodiment t424020.The response message may include a URL through which address informationcan be acquired in addition to basic 2000K message information. The URLmay be URL information for acquiring the address of a Websocket endpointor URL information for acquiring the address of an HTTP service URL.Alternatively, the URL may be URL information for obtaining both. In theillustrated format, the URL information for acquiring the address of aWebsocket endpoint is included.

The application of the CD may send a request for address information tothe URL using HTTP GET. Here, the GET message may have a format shown inembodiment t424030. The request message using GET may be transmitted toa URL of address information acquired from the PD. In addition, hostinformation of an IP address/port of description may be used.Furthermore, a language preferred by a control point may be used.

For example, when the URL for acquiring the address information ishttp://192.168.1.10:8080/WSEndpoints (assuming Websocket), the GETmessage using this URL may be configured as shown in embodiment t424040.

Subsequently, a response message to the address information requestmessage may be returned as described above. The response message mayinclude address information. The address information may be the addressof the Websocket endpoint or the address of the HTTP service URL.

FIG. 92 illustrates formats of a response message delivering addressinformation in a process for discovering a Websocket endpoint or an HTTPservice URL using a URL of a response header to a DDD request accordingto an embodiment of the present invention.

In the aforementioned Websocket based architecture embodiment #1, aresponse message format according to the illustrated embodiment t425010may be used.

As shown, address information about endpoints such as theservice/content identification endpoint and the ESG information endpointmay be included in the message. Since the message format is used inWebsocket based architecture embodiment #1, the pieces of addressinformation about the endpoints may be arranged.

The message format according to the illustrated embodiment t425010 maybe used in the aforementioned HTTP based architecture embodiment #1. Inthis case, the address information of the Websocket endpoints can bereplaced by URL address information of service URLs. Accordingly,element names may be changed. Similarly, since the message format isused in HTTP based architecture embodiment #1, the pieces of addressinformation of the service URLs may be arranged.

In the aforementioned Websocket based architecture embodiment #2, amessage format according to the illustrated embodiment t425020 may beused.

The message format according to the illustrated embodiment t425020 maybe used in the aforementioned HTTP based architecture embodiment #2. Inthis case, the address information of the Websocket companion endpointcan be replaced by address information of a companion service URL.Accordingly, element names may be changed. Similarly, since the messageformat is used in HTTP based architecture embodiment #2, only theaddress information of the companion service URL may be includedtherein.

In the aforementioned Websocket based architecture embodiment #3, amessage format according to the illustrated embodiment t425030 may beused.

The message format according to the illustrated embodiment t425030 mayinclude n Websocket endpoints. For example, address information of acompanion endpoint that executes the service/content identificationfunction, the ESG information delivery function, etc. and addressinformation of the app-to-app communication endpoint may be included inthe message format.

While the illustrated formats include address information in anadditionalData element, the message may include other pieces ofinformation according to embodiments. Here, a structure and a form inwhich address information is included in the message may be configuredin various manners according to embodiments.

FIG. 93 illustrates a Websocket based handshake & connection process(after discovery) according to an embodiment of the present invention.

As described above, a PD may serve as a Websocket server and a CD maycorrespond to a Websocket client. The PD may include a Websocket serverand/or a companion service module. The companion service module mayprovide information necessary for a companion device or perform overallmanagement related to companion services. The companion service modulemay be a hardware module.

The Websocket server of the PD may provide Websocket endpoints. Anapplication available in a web browser in the CD may be executed. Theweb browser may also provide a Websocket client.

First, the companion service module of the PD may request generation ofa Websocket endpoint from the Websocket server (t426010). For example, arequest in the form of @ServerEndpoint(“/WS_AA”) in Java format may bedelivered. Here, “/WS_AA” may refer to a related URL. Through thisprocess, the Websocket server can generate the Websocket endpoint.

An application of the CD may call an API for generating a Websocketobject (t426020). The API in the name of newWebsocket may have theaddress of the Websocket endpoint as a variable thereof. For example,ex_Websocket can be defined in the form ofex_Websocket=newWebsocket(ws://192.168.1.11:8080/WS_AA). Through thisprocess, the Websocket object can be generated in the CD. Here,handshake between the endpoint of the Websocket server in the PD and theWebsocket object of the CD can be performed (t426030).

The application of the CD may call an APR for adding OpenEventHandler(t426040). The API may be WebsocketObject.onopen( ) For example, ahandler can be added in a manner of ex_Websocket.onopen(. . . ). In thisprocess, the Websocket server and a client can be connected (t426050).The Websocket client can notify the application of the CD of opening ofconnection (t426060).

FIG. 94 illustrates a handshake & connection process for Websocket basedapp-to-app communication (after discovery) according to an embodiment ofthe present invention.

In a Websocket based architecture, app-to-app communication can beperformed between an application executed in a PD and an applicationexecuted in a CD. As described above, when the application of the PD isconnected to a Websocket server and the application of the CD is alsoconnected to the Websocket server, the Websocket server can relaymessages and data between the applications.

First, the application of the PD may call an API in order to generate anew Websocket object in a Websocket client in the PD. The aforementionednewWebsocket API may be used. For example, the API can be used such aslocal_Websocket=newWebsocket(ws://localhost:8080/ApptoApp). In thisprocess, the Websocket object for the application of the PD can begenerated.

A companion service module of the PD may call an API from the Websocketserver to generate a Websocket endpoint (t427020 and t427030). Thisprocess has been described above. In this case, an endpoint forapp-to-app communication needs to be generated, and thus a URL (e.g.,/ApptoApp) related to app-to-app communication can be used as avariable. Thereafter, the local Websocket client of the PD and theWebsocket server can perform a handshake process (t427040).

The application of the CD may also generate a Websocket object(t427050). The process for generating the Websocket object is the sameas the aforementioned process. In this case, since the Websocket objectis a Websocket object for app-to-app communication, the Websocket objectcan be defined in the form ofremote_Websocket=newWebsocket(ws://192.168.1.11:8080/ApptoApp).Subsequently, the Websocket server of the PD and the Websocket object ofthe CD can perform a handshake process (t427060).

The Websocket client of the PD and the Websocket client of the CD maycall an API in order to add OpenEventHandler (t427091 and t427090). Thisprocess is the same as the aforementioned process. Accordingly, theWebsocket clients can be connected to the Websocket server (t427070 andt427100). Upon connection, the Websocket clients can notify theapplications of opening of connection through an event (t427080 andt427110).

Upon completion of the aforementioned processes, the application of theCD and the application of the PD can communicate each other (t427120).The applications of both sides can deliver messages to each otherthrough the Websocket server. That is, the Websocket server can relay amessage sent from one client to the other client. Such a two-waycommunication process will be described in detail below.

FIG. 95 illustrates a Websocket based two-way communication process(after connection) according to an embodiment of the present invention.

A case in which the application of the CD and the Websocket server ofthe PD have been connected through the aforementioned processes isassumed (t428010). As described above, the Websocket client can notifythe application of the CD of opening of connection (t428020).

The companion service module may call an API in order to receive amessage (t428030). For example, an API such as @OnMessage in the Javaformat can be used. Accordingly, the Websocket server may be ready toreceive a message (ready receive).

The application of the CD may call an API for adding MessageEventHandler(t428040). For example, an API such as WebsocketObject.onmessage( ) canbe called. In the case of an object such as ex_Websocket in theaforementioned example, an API may be called in the form ofex_Websocket.onmessage(. . . ). Through this process, the Websocketclient of the CD may be ready to transmit/receive messages.

The application of the CD may call an API for sending a message(t428050). For example, an API such as WebsocketObject.send(message1)can be called. In the case of an object such as ex_Websocket in theaforementioned example, an API such as ex_Websocket.send(message1) canbe called. Accordingly, a message (message 1) can be delivered to theWebsocket server (t428060).

The Websocket server may deliver the received message (message 1) to thecompanion service module (t428070). The companion service module maydeliver a message (message 2) in response to the message (message 1)(t428080, t428090 and t428100). The companion service module may call anAPI for sending the message (t428080). To transmit an object in a textor JSON format, a Java API such as session.getBasicRemote().sendText(message2) or session.getBasicRemote( ).sendObject (message2)can be called.

FIG. 96 illustrates a Websocket based app-to-app two-way communicationprocess (after connection: CD-to-PD) according to an embodiment of thepresent invention.

A case in which the application of the CD, the Websocket server of thePD and the application executed in the PD have been connected throughthe aforementioned processes is assumed. The applications may havereceived information indicating opening of connection from the Websocketclient through an event.

As described above, the companion service module may call an API inorder to receive a message and the Websocket server may be ready toreceive a message through the API (t429030). The application of the PDmay call an API in order to add MessageEventHandler and the Websocketclient of the PD may be ready to receive a message (t429040). Theapplication of the CD may call an API such that the Websocket client isready to receive a message (t429020). The detailed process has beendescribed above.

The application of the CD may call an API in order to send a message(t429050). The API may be the aforementioned API. For example, an APIsuch as remote Websocket.send(message1) can be used. A message can bedelivered to the Websocket server through the API (t429060). TheWebsocket server can deliver the message (message 1) to the companionservice module (t429070).

The companion service module may search for a local Websocket session inorder deliver the message to the local Websocket client of the PD. Thecompanion service module may call an API in order to deliver the message(message 1) when the local Websocket session is found (t429080). Here, aJava API such as session.getBasicRemote( ).sendText(message1) orsession.getBasicRemote( ).sendObject (message1) can be called in orderto transmit an object in a text or JSON format, as described above.

The Websocket server can deliver the message (message 1) to theWebsocket client (t429090) and the Websocket client can deliver themessage (message 1) to the application of the PD (t429100).

FIG. 97 illustrates a Websocket based app-to-app two-way communicationprocess (after connection: PD-to-CD) according to an embodiment of thepresent invention.

A case in which the application of the CD, the Websocket server of thePD and the application executed in the PD have been connected throughthe aforementioned processes is assumed. The applications may havereceived information indicating opening of connection from the Websocketclient through an event.

The Websocket server and the Websocket clients may have been ready totransmit/receive messages through the aforementioned processes.

The application of the PD may call an API in order to send a message(t430010). The API may be the aforementioned API. For example, an APIsuch as local_Websocket.send(message2) can be used. A message can bedelivered to the Websocket server through the API (t430020). TheWebsocket server can deliver the message (message 2) to the companionservice module (t430030).

The companion service module may search for a remote Websocket sessionin order deliver the message to a remote Websocket client of the PD. Thecompanion service module may call an API in order to deliver the message(message 2) when the remote Websocket session is found (t430040). Here,a Java API such as session.getBasicRemote( ).sendText(message2) orsession.getBasicRemote( ).sendObject (message2) can be called in orderto transmit an object in a text or JSON format, as described above.

The Websocket server can deliver the message (message 2) to theWebsocket client (t430050) and the Websocket client can deliver themessage (message 2) to the application of the CD (t430060).

FIG. 98 illustrates an HTTP based request-response process (afterdiscovery) according to an embodiment of the present invention.

It is assumed that all HTTP service URLs have been discovered throughthe above-described discovery process in an HTTP based architecture(t431010).

An application of a CD may call an API and send a request for a messageto an HTTP client (t431020). The HTTP client may send the request to anappropriate URL corresponding to the request of the application fromamong the HTTP service URLs discovered in the discovery process(t431030). Alternatively, the HTTP client may send the request to acompanion service URL according to the aforementioned embodiment. Inthis case, content of the request can be identified through the queryterm of the request.

An HTTP server may deliver the request to a companion service module ina PD (t431040). The companion service module may call an API in order todeliver the requested message (message1) to the CD (t431050).

The HTTP server may deliver the message (message 1) to the HTTP client(t431060) and the HTTP client may deliver the message to the applicationof the CD (t431070).

FIG. 99 illustrates a method for providing a broadcast service by a PDaccording to an embodiment of the present invention.

The method for providing a broadcast service by the PD according to anembodiment of the present invention may include a step of performing adiscovery process with a CD application, a step of establishingWebsocket connection, a step of receiving an EA (Emergency Alert)message and/or step of delivering the EA message to a CD throughWebsocket connection.

First, a companion module of a broadcast reception apparatus whichoperates as a PD may perform a discovery process with a CD applicationexecuted in a companion device (CD). The discovery process has beendescribed above. Here, it is assumed that the CD application is notlaunched by the PD. The CD may multicast an M-SEARCH message. Uponreception of the M-SEARCH message, the PD may reply to the message witha 200 OK message. The header of the 200 OK message may include alocation URL of the PD.

The CD application may send a request for device description to thelocation URL. The request may be performed using the HTTP GET method.Upon reception of the request, the PD or the companion module of the PDmay transmit a first response message to the CD application. Here, thefirst response message may include a first URL in the header thereof.The first URL may be used as an endpoint of a web server provided by thePD. Here, the endpoint of the web server may refer to a service URLprovided by the web server. The first URL may correspond to a companionservice URL used in the aforementioned HTTP based architectures. Theremay be service URLs depending on functions according to an embodiment.In such a case, the first URL may be one of multiple HTTP service URLs.

The companion module of the PD may receive an application informationrequest from the CD application. The CD application may send theapplication information request to the first URL. The companion modulemay transmit a second response message in response to the applicationinformation request. The second response message may include the secondURL in a response message body. The second URL may be used as anendpoint of a Websocket server provided by the PD. Here, the second URLwhich is address information of the corresponding Websocket endpoint maybe a companion Websocket endpoint or an app-to-app Websocket endpoint.

The present embodiment may correspond to the aforementioned embodimentin which an HTTP based web server and a Websocket based Websocket serverare provided by the PD. Specifically, the present embodiment maycorrespond to the embodiment from among the aforementioned embodiments,in which only one companion service URL is provided as an HTTP serviceURL and one companion endpoint and one app-top-app endpoint are providedas Websocket server endpoints. Here, the Websocket companion endpointmay be an endpoint providing functions other than the app-to-appcommunication function. Communication between the PD and the CD may beperformed by a web server (HTTP) or a Websocket server depending onfunctions. For example, ESG delivery may be performed by the web serverand service & content identification, EA (Emergency Alert) messagedelivery and media playback information delivery may be performed by theWebsocket server. Media timeline information may be delivered throughthe web server and/or the Websocket server.

Subsequently, the companion module of the PD may establish Websocketconnection between the Websocket server and the CD application. In thisprocess, the second URL may be used. The method of establishingWebsocket connection (session) has been described above in detail. Here,the Websocket connection may be Websocket connection for connecting a PDapplication and a CD application for app-to-app communication orWebsocket connection for exchanging information between the PD and theCD application.

A reception module of the PD may receive an EA message including EAinformation over a broadcast network or a broadband network. Thereception module may be one of a tuner that receives data through abroadcast network and a network interface that receives data overbroadband or may include both the tuner and the network interface. TheEA message may refer to a message including EA information forannouncing an emergency situation. This has been described above.

The Websocket server of the PD may deliver the received EA message tothe CD through Websocket connection. The delivery process will bedescribed below in detail. Here, the Websocket server may refer to ahardware module or a processor that performs operation corresponding tothe aforementioned Websocket server.

In a method for providing a broadcast service by a PD according toanother embodiment of the present invention, the step of delivering theEA message to the CD may further include a step of executing a PDapplication for processing EA information, a step of executing an EAapplication of the CD by the PD application and/or a step of deliveringthe EA message from the PD application to the EA application of the CDthrough Websocket connection.

When the EA message is received, an internal control module of the PDmay execute an application of the PD related to the EA message. Theapplication of the PD may render the EA message and manage a process ofdelivering the EA message to the CD. The application of the PD mayexecute the EA application in the CD. The EA application may be anapplication having a function of rendering and processing the EA messagein the CD. When the EA application is executed in the CD, app-to-appWebsocket connection may be established between the EA application andthe application of the PD. This process has been described above. Theapplication of the PD may deliver the received EA message to the EAapplication. The EA application may render and process the EA message inthe CD.

In a method for providing a broadcast service by a PD according toanother embodiment of the present invention, the EA message may includeID information for identifying the EA message, expiration timeinformation indicating a time at which the EA message expires and/orcategory information indicating a type of an emergency alert indicatedby the EA message. Information that can be included in the EA messagehas been described above.

A method for providing a broadcast service by a PD according to anotherembodiment of the present invention may further include a step in whichthe CD application requests timeline information using the HTTP GETmethod and/or a step in which the PD delivers an HTTP response messageto the CD application. The aforementioned web server of the PD may berequested to provide the timeline information. Here, the timelineinformation may refer to information about a media timeline of abroadcast service being provided by the PD. The web server of the PDtransmits the response message to the request to the CD application. Theresponse message may include UTC information and media time informationin a pair. The UTC information may refer to absolute time informationwhich is current UTC time information and the media time information mayrefer to media time information at the UTC time.

A method for providing a broadcast service by a PD according to anotherembodiment of the present invention may further include a step in whichthe CD application requests a service identification message from theWebsocket server of the PD and/or a step in which the Websocket serverdelivers the service identification message to the CD application. Therequest and a response thereto may be performed through Websocketconnection. Here, the PD may deliver the service identification messageto the CD application through notification without a request of the CDapplication according to an embodiment. The service identificationmessage may include at least one piece of service related information orat least one piece of content related information acquired fromelectronic service guide (ESG) data. Service related information may beincluded in the service identification message in the form of a serviceelement and content related information may be included in the serviceidentification message in the form of a content element.

In a method for providing a broadcast service by a PD according toanother embodiment of the present invention, the service identificationmessage may include component information and/or content iteminformation related to each piece of content. The content element of theservice identification message may include component elements thatdescribe components included in the corresponding content and/or contentitem elements that describe files/data related to the correspondingcontent. Here, content may correspond to a program of the correspondingbroadcast service (channel).

Here, the component information may include information about componentshaving continuous and presentable data of the corresponding content. Forexample, the components may correspond to an audio component, a videocomponent, a closed caption component, etc. In addition, each piece ofcomponent information may include URL information for accessing thecorresponding component. The URL information may be service URLinformation of the PD or URL information of a server provided by aservice provider.

The content item information may include information about additionaldata components of the corresponding content. Here, additional datacomponents may refer to data such as the aforementioned app-basedenhancement components or applications, and signaling informationrelated to applications. In addition, each piece of content iteminformation may include URL information for accessing the correspondingdata. The URL information may be service URL information of the PD orURL information of a server provided by the service provider.

In a method for providing a broadcast service by a PD according toanother embodiment of the present invention, URL information foraccessing an additional data component may be used to acquire data forproviding app-based enhancement for a broadcast service.

A method for providing a broadcast service by a CD according to anembodiment of the present invention will be described. This method isnot shown in the drawings.

The method for providing a broadcast service by a CD according to anembodiment of the present invention may include a step in which alauncher of the CD executes an application of the CD, a step in whichthe application of the CD performs a discovery process with a PD using anetwork interface of the CD, a step in which the application of the CDestablishes Websocket connection with a Websocket server of the PD usinga Websocket client of the CD and/or a step in which the application ofthe CD receives an EA message using the Websocket client of the CD. Thediscovery process between the CD application and the PD may be performedby a companion module of the CD. The CD application may send a devicedescription request using the companion module, send an applicationinformation request to the aforementioned first URL and acquire aresponse to the requests. In addition, an EA application of the CD maybe executed by a PD application to perform app-to-app communicationthrough Websocket connection. The EA application may receive an EAmessage through the app-to-app communication.

Methods for providing a broadcast service by a CD according toembodiments of the present invention may correspond to theabove-described method for providing a broadcast service by a PDaccording to embodiments of the present invention. Methods for providinga broadcast service by a CD may be performed by hardware modulescorresponding to modules (e.g., the companion module, the receptionmodule, the internal control module, the web server and the Websocketserver) used in the methods for providing a broadcast service by a PD.Methods for providing a broadcast service by a CD may have embodimentscorresponding to the above-described embodiments of the method forproviding a broadcast service by a PD.

The aforementioned steps may be omitted or replaced by other stepsperforming similar/identical operations according to embodiments.

FIG. 100 illustrates a broadcast reception apparatus operating as a PDaccording to an embodiment of the present invention.

The broadcast reception apparatus operating as a PD according to anembodiment of the present invention may include the aforementionedcompanion module, reception module, internal control module, web serverand/or Websocket server. The blocks and modules have been describedabove. Here, the web server/Websocket server may refer to hardwaremodules or processors that perform operations corresponding to theaforementioned web server/Websocket server.

The broadcast reception apparatus operating as a PD according to anembodiment of the present invention and internal modules/blocks thereofmay perform the aforementioned embodiments of the methods for providinga broadcast service by a PD.

An apparatus operating as a CD according to an embodiment of the presentinvention will be described. This apparatus is not shown in thedrawings.

The apparatus operating as a CD according to an embodiment of thepresent invention may include the aforementioned launcher, companionmodule and/or network interface. The blocks and modules have beendescribed above.

The apparatus operating as a CD according to an embodiment of thepresent invention and internal modules/blocks thereof may perform theaforementioned embodiments of the methods for providing a broadcastservice by a CD.

The internal blocks/modules of the aforementioned apparatus may beprocessors that perform continuous processes stored in a memory and maybe hardware elements provided inside/outside the apparatus according toan embodiment.

The aforementioned modules may be omitted or replaced by other modulesperforming similar/identical operations according to embodiments.

FIG. 101 illustrates conversion of an ESGData state variable in XMLformat into an ESGData state variable in JSON format according toanother embodiment of the present invention.

The broadcast reception apparatus according to an embodiment of thepresent invention may employ various protocols such as HTTP (HypertextTransfer Protocol), RTP (Real-time Transport Protocol), XMPP (ExtensibleMessaging and Presence Protocol), FTP (File Transfer Protocol) andWebsocket in order to deliver messages including various types ofinformation (e.g., ESG data) used for communication between devices forvarious purposes.

When the broadcast reception apparatus according to an embodiment of thepresent invention delivers a message used for communication betweendevices through the various protocols, the broadcast reception apparatusmay deliver data in various types (e.g., a string, an integer, afloating point, Boolean, a character, an array, a list, etc.) defined inthe protocols. To more structurally represent, deliver and store complexdata, the broadcast reception apparatus may use Markup formats such asXML (Extensible Markup Language), HTML (Hypertext Markup Language),XHTML (Extensible Hypertext Markup Language) and JSON (JavaScript ObjectNotation) or text and image format. The formats employed by thebroadcast reception apparatus are not limited to a specific format.

A description will be given of a method for delivering a message (e.g.,a state variable) including ESG data by the broadcast receptionapparatus to a companion device using the Websocket protocol. In thiscase, the broadcast reception apparatus may convert an ESGData statevariable including ESG data into an ESGData state variable in the JSONformat and deliver the ESGData state variable in the JSON format to acompanion screen device using the Websocket protocol.

FIG. (a) illustrates an embodiment in which ESG data is set to theESGData state variable in XML (or XML data structure). The ESGData statevariable has been described above in detail.

Referring to FIG. (b), the ESGData state variable in XML of FIG. (a) canbe converted into the ESGData state variable in the JSON format. Detailsof the ESGData state variable in the JSON format are the same as detailsof the ESGData state variable in XML.

In this manner, any data in XML (XML data structure) can be convertedinto data in JSON format. Data in JSON format may be referred to as aJSON object. The JSON object may be delivered from the broadcastreception apparatus (e.g., a primary device) to a companion devicethrough the Websocket protocol.

FIG. 102 illustrates a process for delivering the ESGData state variablein JSON format to a companion device using WebSocket protocol accordingto another embodiment of the present invention.

The illustrated CD may refer to a companion device and the illustratedPD (Primary Device) may refer to a receiver or a broadcast receptionapparatus.

The CD may generate a Websocket object by calling a Websocket API usingthe following syntax (C58003).

[Construct Websocket Object]

Webs ocketobjectname=new Websocket(Websocket address)

Ex) WS_ESG=new Websocket(“ws://Tvhost:8080/ESGServer”)

Here, the name of the generated Websocket object may be “WS_ESG”, thecalled Websocket API may be “new Websocket” for generating a newWebsocket, and the address of the Websocket server may be“ws://Tvhost:8080/ESGServer”.

Then, the companion device may open Websocket connection by calling aWebsocket API using the following syntax (C58005).

[Open a Websocket Connection]

Ex) WS_ESG.onopen=function {˜˜˜}

Here, “WS_ESG.onopen” may be an open event handler for openingWebsocket. “function {˜˜˜}” may be a Websocket API opening Websocketconnection.

In this state (C58010), the ESGData state variable of the broadcastreception apparatus may not have any value.

A service/content provider may transmit ESG data over a broadcastnetwork or a broadband channel (C58020). The ESG data may be receivedthrough a reception unit or a network interface of the broadcastreception apparatus. Here, the reception unit may be the aforementionedbroadcast interface or tuner.

The broadcast reception apparatus may signal the received ESD data(C58030).

Then, the broadcast reception apparatus and the companion device mayopen Websocket connection (C58035).

The method of opening Websocket connection has been described above. Forexample, an application processor (not shown) included in the broadcastreception apparatus may send a request for connection with the companiondevice to a network processor (not shown). Then, the network processormay receive the connection request from the companion device. Thenetwork processor may search for a matching connection request of theapplication processor on the basis of information received from thecompanion device. The network processor may connect the companion devicewith the application processor of the broadcast reception apparatus whenthe matching connection request is found. Here, the applicationprocessor may be an application module or an application browser. Thenetwork processor may be a Websocket server.

When Websocket connection between the broadcast reception apparatus andthe companion device is open, the broadcast reception apparatus and thecompanion device switch to a state in which they can transmit and/orreceive messages.

Then, the companion device may transmit/receive various messages to/fromthe broadcast reception apparatus using the following event handler(C58037).

For example, the event handler may include a Message Event Handler, anError Event Handler and/or a Close Event Handler.

Here, the Message Event Handler is an event handler for transmittingand/or receiving messages between the broadcast reception apparatus andthe companion screen and a syntax therefor is as follows.

[Message Event Handler]

EX) WS_ESG.onmessage=function {˜˜˜}

Here, the Error Event Handler is an event handler for transmittingand/or receiving messages related to errors in Websocket connection, thebroadcast reception apparatus and/or the companion device and a syntaxtherefor is as follows.

[Error Event Handler]

EX) WS_ESG. onerror=function {˜˜˜}

Here, the Close Event Handler is an event handler for closing Websocketconnection and a syntax therefor is as follows.

[Close Event Handler]

EX) WS_ESG. onclose=function {˜˜˜}

Thereafter, the broadcast reception apparatus may store (or set) the ESGdata in the ESGData state variable (C58040).

For example, the ESGData state variable may be in XML or JSON format.When the broadcast reception apparatus initially sets the ESG data inthe ESGData state variable in XML, the broadcast reception apparatus mayconvert the state variable in XML into a state variable in the JSONformat.

Then, the broadcast reception apparatus may deliver the JSON object ofthe ESGData state variable to the companion device through the Websocketprotocol (C58050).

Upon reception of the ESGData state variable, the companion device mayparse the ESGData state variable (C58060) and then expose the ESG datathrough a UI according to the parsed value (C56070).

Here, to show the ESG data to a user, the companion device may representthe UI at a native level or represent the same in an application.

The companion device may represent the ESG data in various mannersaccording to various embodiments. When the ESG data is received, thecompanion device may immediately expose the ESG data in any form to theuser according to an embodiment. In another embodiment, when the ESGdata is received, the companion device may send a notification messageto the user and expose the ESG data when the user executes thecorresponding application. In another embodiment, when the ESG data isreceived, the companion device has the ESG data in the background andexposes the ESG data to the user when the user directly executes anapplication for seeing the ESG data.

FIG. 103 illustrates a hybrid broadcast reception device according to anembodiment of the present invention. The hybrid broadcast system maytransmit a broadcast signal in conjunction with a terrestrial broadcastnetwork and an Internet network. The hybrid broadcast reception devicemay receive a broadcast signal through a terrestrial broadcast network(broadcast) and an Internet network (broadband). The hybrid broadcastreception device may include a physical layer module, a physical layerI/F module, a service/content acquisition controller, an Internet accesscontrol module, a signaling decoder, a service signaling manager, aservice guide manager, an App signaling manager, an alert signalmanager, an alert signal parser, a targeting signal parser, a streamingmedia engine, a non-real-time file processor, a component synchronizer,a targeting processor, an application processor, an A/V processor, adevice manager, a data sharing and communication unit, a redistributionmodule, a companion device and/or an external module.

The physical layer module(s) may receive and process broadcast-relatedsignals through a terrestrial broadcast channel, convert the same intoappropriate forms, and transmit the converted signals to the physicallayer I/F module.

The physical layer I/F module(s) may acquire IP datagrams from theinformation obtained from the physical layer module. In addition, thephysical layer I/F module may convert the acquired IP datagram or thelike into a specific frame (for example, RS frame, GSE).

The service/content acquisition controller may perform controloperations for acquiring services, content and signaling data associatedtherewith over a broadcast and/or broadband channel.

The Internet access control module(s) may control receiver operations toacquire services, content, and the like over a broadband channel.

The signaling decoder may decode the signaling information acquired overa broadcast channel or the like.

The service signaling manager may extract, parse, and manage signalinginformation related to service scan and services/content from the IPdatagram and the like.

The service guide manager may extract announcement information from IPdatagrams, manage an SG (Service Guide) database, and provide a serviceguide.

The App signaling manager may extract, parse, and manage signalinginformation related to application acquisition and the like from IPdatagrams and the like.

The alert signal parser may extract, parse, and manage alerting relatedsignaling information from IP datagrams and the like.

The targeting signal parser may extract, parse, and manage signalinginformation related to service/content personalization or targeting fromIP datagrams and the like. The targeting signal parser may also deliverthe parsed signaling information to the targeting processor.

The streaming media engine may extract and decode audio/video data forA/V streaming from IP datagrams and the like.

The non-real time file processor may extract, decode, and manage NRTdata and file type data such as applications from IP datagrams and thelike.

The component synchronizer may synchronize services and content such asstreaming audio/video data and NRT data.

The targeting processor may process operations related topersonalization of the service/content based on the targeting signalingdata received from the targeting signal parser.

The application processor (App processor) may processapplication-related information, the status of a downloaded applicationand display parameters.

The A/V processor may perform audio/video rendering related operationsbased on decoded audio and video data, application data, and the like.

The device manager may perform connection and data exchange with anexternal device. The device manager may also perform management ofexternal devices such as addition/deletion/update of operativelyconnectable external devices.

The data sharing and communication unit (Data Sharing & Comm.) mayprocess information related to data transmission and exchange betweenthe hybrid broadcast receiver and an external device.

Here, the data that may be transmitted and exchanged may be signaling,A/V data, and the like.

The redistribution module(s) may acquire related information about thenext generation broadcast service and content when the broadcastreceiver cannot directly receive the terrestrial broadcast signal. Theredistribution module may also support acquisition of broadcast servicesand content by the next generation broadcast system when the broadcastreceiver cannot directly receive the terrestrial broadcast signal.

The companion device(s) may be coupled to the broadcast receiver of thepresent invention to share audio, video, or signaling-containing data.The companion device may refer to an external device connected to thebroadcast receiver.

An external management module (External Management) may refer to amodule for providing broadcast service/content, for example, a nextgeneration broadcast service/content server. The external module mayrefer to an external device connected to the broadcast receiver.

FIG. 104 is a block diagram illustrating a hybrid broadcast receiveraccording to an embodiment of the present invention.

The hybrid broadcast receiver may receive the hybrid broadcast servicethrough operative connection of terrestrial broadcast and broadband inthe DTV service of the next generation broadcast system. The hybridbroadcast receiver may receive broadcast audio/video (A/V) contenttransmitted through a terrestrial broadcast and receive part ofenhancement data or broadcast A/V content associated therewith in realtime through broadband. In this specification, the broadcast audio/video(A/V) content may be referred to as media content.

The hybrid broadcast receiver may include a physical layer controllerD55010, a tuner D55020, a physical frame parser D55030, a link layerframe parser D55040, an IP/UDP datagram filter D55050, an ATSC 3.0 DTV(Digital Television) Control Engine D55060, an ALC/LCT+ Client D55070, atiming control D55080, a signaling parser D55090, a DASH (DynamicAdaptive Streaming over HTTP) client D55100, an HTTP access clientD55110, an ISO BMFF parser D55120, and/or a media decoder D55130. Thephysical layer controller D55010 may control operations of the tunerD55020, the physical frame parser D55030, and the like using radiofrequency (RF) information about a terrestrial broadcast channel to bereceived by the hybrid broadcast receiver.

The tuner D55020 may receive and process broadcast related signalsthrough a terrestrial broadcast channel and convert the same into anappropriate form. For example, the tuner D55020 may convert a receivedterrestrial broadcast signal into a physical frame.

The physical frame parser D55030 may parse the received physical frameand acquire a link layer frame through related processing.

The link layer parser D55040 may acquire link layer signaling from thelink layer frame or perform related operations to acquire an IP/UDPdatagram or an MPEG-2 TS. The link layer parser D55040 may output atleast one IP/UDP datagram or the like.

The IP/UDP datagram filter D55050 may filter a specific IP/UDP datagramfrom at least one received IP/UDP datagram or the like. That is, theIP/UDP datagram filter D55050 may selectively filter an IP/UDP datagramselected by the ATSC 3.0 DTV control engine D55060 among the at leastone IP/UDP datagram output from the link layer parser D55040. The IP/UDPdatagram filter D55050 may output an application layer transportprotocol packet such as ALC/LCT+.

The ATSC 3.0 DTV control engine D55060 may serve as an interface betweenmodules included in each hybrid broadcast receiver. The ATSC 3.0 DTVcontrol engine D55060 may also provide necessary parameters for eachmodule, thereby controlling the operation of each module. In the presentinvention, the ATSC 3.0 DTV control engine D55060 may deliver a mediapresentation description (MPD) and/or an MPD URL to the DASH clientD55100. In the present invention, the ATSC 3.0 digital televisioncontrol engine D55060 may also deliver a delivery mode and/or atransport session identifier (TSI) to the ALC/LCT+ client D55070. Here,TSI may represent the identifier of a session for transmitting atransport packet including a signaling message such as MPD or MPD URLrelated signaling, for example, the identifier of a FLUTE session or anALC/LCT+ session, which is an application layer transmission protocol.The TSI may correspond to the Asset id of MMT.

The ALC/LCT+ client D55070 may process application layer transportprotocol packets such as ALC/LCT+, and collect and process a pluralityof packets to create one or more ISO Base Media File Format (ISOBMFF)objects. The application layer transport protocol packets may includeALC/LCT packets, ALC/LCT+packets, ROUTE packets, and/or MMTP packets.

The timing control D55080 may process a packet including system timeinformation to control the system clock.

The signaling parser D55090 may acquire and parse DTV broadcast servicerelated signaling, and generate and manage a channel map and the likebased on the parsed signaling. In the present invention, the signalingparser may parse the extended MPD or MPD related information from thesignaling information.

The DASH client D55100 may perform operations related to real-timestreaming or adaptive streaming. The DASH client D55100 may receive DASHcontent from the HTTP server through the HTTP access client D55110. TheDASH client D55100 may process the received DASH segment and output anISO Base Media File Format object. In the present invention, the DASHclient D55100 may deliver a Fully Qualified Representation ID or asegment URL to the ATSC 3.0 DTV control engine D55060. Here, the FullyQualified Representation ID may refer to an ID that combines, forexample, the MPD URL, period@id, and representation@id. The DASH clientD55100 may also receive the MPD or MPD URL from the ATSC 3.0 DTV controlengine D55060. The DASH client D55100 may receive a desired media streamor DASH segment from the HTTP server using the received MPD or MPD URL.In this specification, the DASH client D55100 may be referred to as aprocessor.

The HTTP access client D55110 may make a request for specificinformation to the HTTP server, and may receive and process a responsefrom the HTTP server. Here, the HTTP server may process the requestreceived from the HTTP access client and provide a response thereto.

The ISO BMFF parser D55120 may extract audio/video data from the ISOBase Media File Format object.

The media decoder D55130 may decode the received audio and/or video dataand perform processing to present the decoded audio/video data.

The hybrid broadcast receiver of the present invention is required toextend or modify the MPD in order to provide the hybrid broadcastservice through operative connection between the terrestrial broadcastnetwork and the broadband. The terrestrial broadcast system may transmitthe extended or modified MPD, and the hybrid broadcast receiver mayreceive the broadcast or broadband content using the extended ormodified MPD. That is, the hybrid broadcast receiver may receive theextended or modified MPD through terrestrial broadcasting and receivecontent via terrestrial broadcasting or broadband based on MPD. Thefollowing describes elements and attributes that should be additionallyincluded in the extended or modified MPD compared to the existing MPD.In the following description, the extended or modified MPD may bereferred to as an MPD.

The MPD may be extended or modified to represent ATSC 3.0 services. Anextended or modified MPD may additionally includeMPD@anchorPresentationTime, Common@presentable, Common. Targeting,Common. TargetDevice and/or Common@associatedTo.

MPD@anchorPresentationTime may represent the presentation time anchor ofsegments included in the MPD, that is, a base time. Hereinafter,MPD@anchorPresentationTime may be used as an effective time of the MPD.

MPD@anchorPresentationTime may represent the earliest playback point intime among the segments included in the MPD.

The MPD may further include common attributes and elements. The commonattributes and elements may be applied to the AdaptionSet,Representation, SubRepresentation, and the like in the MPD.Common@presentable may indicate that the media described by MPD is apresentable component.

Common.Targeting may indicate the targeting properties and/orpersonalization properties of the media described by the MPD.

Common.TargetDevice may represent a target device or target devices ofthe media described by the MPD.

Common@associatedTo may represent an adaptationSet and/or representationassociated with the media described by the MPD.

In addition, the MPD@id, Period@id, and AdaptationSet@id included in theMPD may be required to specify the media content described by the MPD.In other words, the DASH client may specify the content to be receivedas MPD@id, Period@id, and AdaptationSet@id based on the MPD and deliverthe same to the ATSC 3.0 DTV control engine. The ATSC 3.0 DTV controlengine may receive the content and deliver the same to the DASH client.

FIG. 105 shows a protocol stack of a next generation hybrid broadcastsystem according to an embodiment of the present invention.

As shown in the figure, a next generation broadcast system supportingIP-based hybrid broadcasting may encapsulate audio or video data of abroadcast service in an ISO Base Media File Format (hereinafter referredto as ISO BMFF). Here, the encapsulation may be in the form of a DASHsegment or an MPU (Media Processing Unit) of MMT. In addition, the nextgeneration broadcast system may transmit encapsulated data over thebroadcast network and the Internet network equally or differentlyaccording to the properties of each transmission network. The nextgeneration broadcast system may also transmit the encapsulated datausing at least one of broadcast or broadband. In case of broadcastnetwork, the broadcast system may transmit data encapsulated in ISO BaseMedia File (ISO BMFF) through an application layer transport protocolpacket supporting real time object transmission. For example, thebroadcast system may encapsulate the data with Real-Time Object Deliveryover Unidirectional Transport (ROUTE) or MMTP transport packet. Then,the broadcast system may generate an IP/UDP datagram from theencapsulated data, and transmit the same through a broadcast signal.When broadband is used, the broadcast system may transmit theencapsulated data to the receiving side based on a streaming techniquesuch as DASH.

In addition, the broadcast system may transmit the signaling informationof the broadcast service in the following manner. In the case of abroadcast network using broadcasting, the broadcast system may transmitsignaling information through the physical layer of the next generationbroadcast transmission system and the broadcast network according to theattribute of the signaling. Here, the broadcast system may transmitsignaling information through a specific data pipe (DP) of a transportframe included in the broadcast signal. The broadcast signaling may beencapsulated in a bit stream or an IP/UDP datagram. When usingbroadband, the broadcast system may return signaling data in response tothe request of the receiver.

In addition, the broadcast system may transmit the ESG or NRT content ofthe broadcast service in the following manner. In the case of abroadcast network, the broadcast system may encapsulate ESG or NRTcontent in an application layer transport protocol packet, for example,Real-Time Object Delivery over Unidirectional Transport (ROUTE), MMTPtransport packet, or the like. Then, the broadcast system may generatean IP/UDP datagram from the encapsulated ESG or NRT content and transmitthe same through a broadcast signal. When using broadband, the broadcastsystem may return the ESG or NRT content in response to the request ofthe receiver.

FIG. 106 shows a structure of a transport frame transmitted to aphysical layer of a next generation broadcast transmission systemaccording to an embodiment of the present invention. The next generationbroadcast system may broadcast a transport frame. In the figure, P1,located at the front part of a transport frame, may refer to a symbolincluding information for transport signal detection. P1 may containtuning information and the receiver may decode the L1 part located afterP1 based on the parameters contained in the P1 symbol. The broadcastsystem may include information on the configuration of the transportframe and the characteristics of each data pipe (DP) in the L1 part.That is, the receiver may obtain information on the configuration of thetransport frame and the characteristics of each DP by decoding the L1part. In addition, the receiver may acquire information to be sharedbetween the DPs via a common DP. Depending on the embodiment, thetransport frame may not include the common DP.

In the transport frame, components such as Audio, Video, and Data aretransmitted in the interleaved DP area composed of DP1 to DP n. Here, aDP through which a component constituting each service (channel) istransmitted may be signaled through L1, common PLP, or the like.

In addition, the next generation broadcast system may transmitinformation for quickly acquiring information on a service included in atransport frame. That is, the next generation broadcast system mayenable the next generation broadcast receiver to quickly acquire thebroadcast service and the content related information included in thetransport frame. In addition, when a service/content generated by one ormore broadcast stations exists in the frame, the next generationbroadcast system may enable the receiver to efficiently recognize theservice/content according to the broadcast stations. That is, thenext-generation broadcast system may transmit service list informationfor a service in a transport frame.

The broadcast system may transmit broadcast service related informationthrough a separate channel, for example, a Quick Information Channel(FIC), in order to enable the receiver to quickly scan the broadcastservice and content within the frequency.

As shown in the middle part of FIG. 106, the broadcast system maytransmit information for scan and acquiring broadcast services in atransport frame. Herein, the area including the information for scan andacquisition of broadcast services may be referred to as FIC. Thereceiver may acquire information on the broadcast service generated andtransmitted by one or more broadcast stations through the FIC, therebymaking it possible to easily and quickly perform scan of the broadcastservices available on the receiver.

In addition, a specific DP included in the transport frame may operateas a base DP for quickly and robustly transmitting signaling of abroadcast service and content transmitted in the corresponding transportframe. The data transmitted through each DP of the transport frame ofthe physical layer are exemplarily shown at the bottom of FIG. 57. Thatis, link layer signaling or IP datagrams may be encapsulated in aspecific type of generic packet and then transmitted through the DP.Here, the generic packet may include signaling data. Link (low) layersignaling may include signaling related to quick servicescan/acquisition, context information of IP header compression,emergency alert, and the like.

FIG. 107 is a diagram illustrating a transport packet of an applicationlayer transmission protocol according to an embodiment of the presentinvention.

The application layer transport session may be configured by acombination of an IP address and a port number. If the application layertransport protocol is Real-Time Object Delivery over UnidirectionalTransport (ROUTE), the ROUTE session may consist of one or more LayeredCoding Transport (LCT) sessions. For example, when one media component(e.g., a DASH Representation or the like) is transmitted through one LCTtransport session, one or more media components may be multiplexed andtransmitted through one application transport session. Further, one ormore transport objects may be delivered through one LCT transportsession, and each transport object may be a DASH segment associated witha DASH representation delivered through the transport session.

For example, if the application layer transport protocol is an LCT-basedprotocol, transport packets may be configured as follows. The transportpacket may include an LCT header, a ROUTE header, and payload data, anda plurality of fields may be included in the transport packet.

The LCT header may include the following fields. The V (version) fieldmay indicate the version information of the corresponding transportprotocol packet. The C field may indicate a flag associated with thelength of the Congestion Control Information field described below. ThePSI field is protocol-specific information and may indicate informationspecified for the protocol. The S field may indicate a flag associatedwith the length of the transport session identifier (TSI) field. The Ofield may indicate a flag associated with the length of the transportobject identifier (TOI) field. The H field may indicate whether ahalf-word (16 bits) is added to the length of the TSI and TOI fields. A(Close Session flag) field may indicate that the session is terminatedor that termination is imminent. The B (Close Object flag) field mayindicate that the object being transmitted is ending or that the end isimminent. The Code point field may indicate information related toencoding or decoding the payload of a packet. For example, the payloadtype may correspond to this information. The Congestion ControlInformation field may contain information associated with congestioncontrol. For example, the information associated with congestion controlmay be the current time slot index (CTSI), the channel number, or thepacket sequence number within the channel. The Transport SessionIdentifier field may indicate the identifier of the transport session.The Transport Object Identifier field may represent an identifier of anobject transmitted through the transport session.

The ROUTE (ALC) header may include transmission of additionalinformation of the preceding LCT header, such as the payload identifierassociated with the forward error correction scheme. The payload datamay represent the substantial data portion of the payload of the packet.

FIG. 108 illustrates a method of transmitting signaling data in a nextgeneration broadcast system according to an embodiment of the presentinvention. The signaling data of the next generation broadcast systemmay be transmitted as shown in the figure. In order to support quickservice/content scan and acquisition by the receiver, the nextgeneration broadcast transmission system may deliver signaling data fora broadcast service delivered by a corresponding physical layer framethrough a Fast Information Channel (FIC). In the present specification,FIC may mean information on a service list. If there is no separate FIC,the signaling data may be transmitted through the path along which thelink layer signaling is delivered. In other words, signaling informationincluding a service and information on components (audio, video, etc.)in the service may be encapsulated and transmitted in IP/UDP datagramsthrough one or more DPs in the physical layer frame. According to anembodiment, the signaling information on a service and servicecomponents may be encapsulated and transmitted in an application layertransport packet (e.g., ROUTE packet or MMTP packet).

The upper part of FIG. 108 shows an embodiment in which theabove-described signaling data is transmitted via FIC and one or moreDPs. Signaling data for supporting rapid service scan/acquisition may betransmitted through FIC, and signaling data including detailedinformation about services and the like may be encapsulated in an IPdatagram and transmitted through a specific DP. In the presentspecification, the signaling data including detailed information onservices and the like may be referred to as service layer signaling.

The middle part of FIG. 108 shows an embodiment in which theabove-described signaling data is transmitted through the FIC and one ormore DPs. Signaling data for supporting rapid service scan/acquisitionmay be transmitted through FIC, and signaling data including detailedinformation about services and the like may be encapsulated in an IPdatagram and transmitted through a specific DP. In addition, a portionof the signaling data, including information about a specific componentincluded in the service may be transmitted through one or more transportsessions in the application layer transmission protocol. For example, aportion of the signaling data may be delivered over one or moretransport sessions within a ROUTE session.

The lower part of FIG. 108 shows an embodiment in which theabove-described signaling data is transmitted through the FIC and one ormore DPs. Signaling data for supporting rapid service scan/acquisitionmay be transmitted through FIC, and signaling data containing detailedinformation about the service may be transmitted through one or moretransport sessions in the ROUTE session.

FIG. 109 shows signaling data transmitted by a next generation broadcastsystem according to an embodiment of the present invention for rapidbroadcast service scan of a receiver.

The present specification proposes signaling information used for a nextgeneration broadcast reception device to scan and acquire a broadcastservice.

In the next generation broadcast system, broadcast services and contentgenerated by one or more broadcast stations within a specific frequencymay be transmitted. The receiver may use the above-described signalinginformation to rapidly and easily scan broadcast stations existingwithin the frequency and the service/content of the correspondingbroadcast stations. This may be represented by syntax as shown in thefigure or may be represented in other formats such as XML.

Signaling information for rapid service scan and acquisition may bedelivered over a rapid information channel (FIC), which is a separatechannel in the physical layer transport frame. In addition, thesignaling information may be transmitted through a common DP, which maytransmit information that may be shared among the data pipes of thephysical layer. Also, In addition, the signaling information may betransmitted through a path along which the signaling of the link layeris transmitted. The above-described signaling information may beencapsulated in an IP datagram and transmitted through a specific DP.

The signaling information may be transmitted through a service signalingchannel through which service signaling is delivered, or a transportsession of the application layer.

The signaling information (FIC information) for rapid service scan andacquisition may include at least one of the following fields. Herein,the FIC information may be referred to as service acquisitioninformation. The FIC_portocol_version field may indicate the protocolversion of the FIC signaling information (version of the structure ofFIC). The TSID field may indicate an identifier of the overall broadcaststream.

The FIC_data_version field may indicate the data version of the FICinstance. The FIC_data_version field may be incremented if there is achange in the content of the FIC. The num_partitions field may representthe number of partitions in the broadcast stream. It is assumed thateach broadcast stream can be transmitted in one or more partitions inorder for the num_partitions field to be used. Each partition maycontain a plurality of DPs by one broadcaster.

Each partition may represent a portion of the broadcast stream used byone broadcaster. The partition_protocol_version field may indicate theversion of the partition structure described above. The base_DP_ID fieldmay indicate an identifier for the base DP of the partition. The base DPmay include a service signaling table. The service signaling table mayinclude a list of all services in the partition.

That is, the service signaling table may list the services to betransmitted. Default properties for each service may also be defined.The base DP may be a robust DP within the partition and may containother signaling tables for the partition. The base DP version field mayindicate version information indicating a change in data transmittedthrough the base DP. For example, in transmitting service signaling orthe like through the base DP, the base_DP_version field may beincremented by 1 when a change in service signaling occurs. Thenum_services field may indicate the number of at least one servicebelonging to the partition. The service_id field may indicate anidentifier for the service. The channel_number field may indicate thechannel number associated with the service. The service_category fieldmay indicate a category of the corresponding service and may indicate,for example, A/V, audio, ESG, CoD, or the like. Theshort_service_name_length field may indicate the length of the namerepresenting the service.

The short_Service_name field may indicate a name representing theservice. The service_status field may indicate the status of the serviceand may indicate an active or suspended, hidden or shown attributedepending on the value thereof.

The service_distribution field may have attributes similar to the“multi-ensemble” flag of the ATSC M/H document. For example, theservice_dstribution field may indicate information about whether theservice is included in the partition, whether the service is partiallyincluded in the partition but is presentable with the partition, whetheranother partition is required for presentation, or whether anotherbroadcast stream is required for presentation.

The sp_indicator field is a service protection flag that may indicatewhether one or more components needed for the presentation areprotected.

FIG. 61 shows signaling data transmitted by a next generation broadcastsystem according to an embodiment of the present invention for rapidbroadcast service scan of a receiver. FIC information (serviceacquisition information) to support rapid broadcast service scan andservice/component acquisition may include information about anapplication layer transport session carrying service and component data.As shown in the figure, the FIC information may be expressed in binaryformat, but may be represented in other formats such as XML according toan embodiment. The FIC information may include the fields asillustrated. The FIC_portocol_version field may indicate the protocolversion of the FIC signaling information (version of the structure ofFIC). The TSID field may indicate an identifier of the overall broadcaststream. The FIC_data_version field may indicate the data version of theFIC instance. The FIC_data_version field may be incremented if there isa change in the content of the FIC. The num_partitions field mayrepresent the number of partitions in the broadcast stream. It isassumed that each broadcast stream can be transmitted in one or morepartitions in order for the num_partitions field to be used. Eachpartition may contain a plurality of DPs by one broadcaster.

Each partition may represent a portion of the broadcast stream used byone broadcaster. The partition_id field may indicate the identifier ofthe partition.

The partition_protocol version field may indicate the version of thepartition structure described above.

The num_services field may indicate the number of at least one componentbelonging to the partition.

The service_id field may indicate an identifier for the service. Theservice_data_version field may indicate a change in service loop data inthe FIC or a change in service signaling data associated with theservice.

The service_data_version_field may be incremented by 1 each time achange occurs in the included service data. The receiver may use theservice_data_version field to detect a change in the service loop dataof the FIC or a change in the signaling associated with the service.

The channel_number field may indicate the channel number associated withthe service.

The service_category field may indicate a category of the correspondingservice and may indicate, for example, A/V, audio, ESG, CoD, or thelike. The short_service_name_length field may indicate the length of thename representing the service. The short_service_name_field may indicatea name representing the service. The service_status field may indicatethe status of the service and may indicate an active or suspended,hidden or shown attribute depending on the value thereof. Theservice_distribution field may have attributes similar to the“multi-ensemble” flag of the ATSC M/H document. For example, theservice_distribution field may indicate information about whether theservice is included in the partition, whether the service is partiallyincluded in the partition but presentable with the partition, whetheranother partition is required for presentation, or whether anotherbroadcast stream is required for presentation. The sp_indicator field isa service protection flag that may indicate whether one or morecomponents needed for the presentation are protected. TheIP_version_flag field may indicate the format of the IP address thatfollows. If the value of the field is 0, it indicates that IPv4 formatis used, and if 1, it indicates that IPv6 address format is used. Thesource_IP_address_flag field may indicate whether source_IP_addr isincluded. If the value of this field is 1, it indicates thatsource_IP_addr exists. The num_transport_session field may indicate thenumber of transport sessions (for example, ROUTE or MMTP sessions) fortransmitting component data of the corresponding service in thebroadcast stream. The source_IP_addr field may indicate the source IPaddress of the IP datagram including the component data of thecorresponding service when the value of the source_IP_address_flag is 1.The_dest_IP_addr field may indicate the destination IP address of the IPdatagram including the component data of the corresponding service. Thedest_UDP_port field may indicate the UDP port number of the UDP datagramthat contains the component data of the corresponding service. TheLSID_DP field may represent a data pipe identifier of the physical layercarrying signaling including detailed information about the transportsession. Here, the signaling including the detailed information aboutthe transport session may be, for example, an LCT session instancedescription including information on the detailed LCT transport sessionof each ROUTE session in the case of ROUTE.

The service_signaling_flag field may indicate whether the transportsession transmits service signaling. When the value ofservice_signaling_flag is 1, it may indicate that the data transmittedthrough the corresponding transport session (for example, ROUTE or MMTPsession) includes service signaling. The Transport session descriptorsfield may contain descriptors at the transport session level. Eachdescriptor is extensible, and each descriptor may include anum_descriptors field. Each descriptor may include as many descriptorloops as the value indicated by the num_descriptors field.

The transport session descriptors field may contain descriptors at thetransport session level. The service descriptors field may includeservice level descriptors. The Partition descriptors field may include apartition level descriptor, and one partition may indicate a part of abroadcast stream used by one broadcaster or the like. The FIC sessiondescriptors field may contain FIC level descriptors. According to anembodiment, each of the fields included in the FIC described above maybe included in a table other than the FIC and transmitted together witha broadcast signal.

FIG. 111 illustrates a method for transmitting FIC-based signalingaccording to an embodiment of the present invention.

The above-mentioned FIC-based signaling may be delivered as shown in thefigure.

The FIC-based signaling may be referred to as service acquisitioninformation or service acquisition signaling. As shown in the figure,the physical layer signaling may include a field for service acquisitioninformation. The field for the service acquisition information mayinform the receiver of whether the service acquisition information (FIC)is parsed. The receiver may parse the service acquisition informationand check whether the data of the service signaling is changed throughthe service data version information. When the service signaling data ischanged, the broadcast signal receiver may check the data pipeidentifier of the physical layer that carries signaling includingdetailed information on the transport session, using the LSID_DP field.The broadcast receiver may verify the details of the transport sessionby parsing the DP indicated by the corresponding DP identifier. That is,the signaling method of the next generation broadcast system includes aprocedure of signaling whether the physical layer signaling parses theservice acquisition information, and the service acquisition informationsignals the location of the detailed information about the transportsession to check the detailed information about the transport session.Here, the detailed information about the transport session may includean MPD transport table, an application signaling table, a transportsession descriptor (LSID), and/or a component mapping table (CMT).

FIG. 112 shows signaling data transmitted by a next generation broadcastsystem according to an embodiment of the present invention for rapidbroadcast service scan of a receiver. FIC information (serviceacquisition information) to support rapid broadcast service scan andservice/component acquisition may include information about anapplication layer transport session carrying service and component data.As shown in the figure, the FIC information may be expressed in binaryformat, but may be represented in other formats such as XML according toan embodiment. The FIC information may include the following fields. TheFIC_portocol version field may indicate the protocol version of the FICsignaling information (version of the structure of FIC). The TSID fieldmay indicate an identifier of the overall broadcast stream. TheFIC_data_version field may indicate the data version of the FICinstance. The FIC_data_version field may be incremented if there is achange in the content of the FIC. The num_partitions field may representthe number of partitions in the broadcast stream. It is assumed thateach broadcast stream can be transmitted in one or more partitions inorder for the num_partitions field to be used. Each partition maycontain a plurality of DPs by one broadcaster.

Each partition may represent a portion of the broadcast stream used byone broadcaster. The partition_id field may indicate the identifier ofthe partition.

The partition_protocol_version field may indicate the version of thepartition structure described above.

The num_services field may indicate the number of at least one componentbelonging to the partition. The service_id field may indicate anidentifier for the service.

The service_data_version field may indicate a change in service loopdata in the FIC or a change in service signaling data associated withthe service.

The service_data_version field may be incremented by 1 each time achange occurs in the included service data. The receiver may use theservice_data_version field to detect a change in the service loop dataof the FIC or a change in the signaling associated with the service.

The channel_number field may indicate the channel number associated withthe service.

The service_category field may indicate a category of the correspondingservice and may indicate, for example, A/V, audio, ESG, CoD, or thelike. The short_service_name_length field may indicate the length of thename representing the service. The short_service_name field may indicatea name representing the service. The service_status field may indicatethe status of the service and may indicate an active or suspended,hidden or shown attribute depending on the value thereof. Theservice_distribution field may have attributes similar to the“multi-ensemble” flag of the ATSC M/H document. For example, theservice_distribution field may indicate information about whether theservice is included in the partition, whether the service is partiallyincluded in the partition but presentable with the partition, whetheranother partition is required for presentation, or whether anotherbroadcast stream is required for presentation. The sp_indicator field isa service protection flag that may indicate whether one or morecomponents needed for the presentation are protected. TheIP_version_flag field may indicate the format of the IP address thatfollows. If the value of the field is 0, it indicates that IPv4 formatis used, and if 1, it indicates that IPv6 address format is used. Thesource_IP_address_flag field may indicate whether source_IP_addr isincluded. If the value of this field is 1, it indicates thatsource_IP_addr exists. The num_transport_session field may indicate thenumber of transport sessions (for example, ROUTE or MMTP sessions) fortransmitting component data of the corresponding service in thebroadcast stream. The source_IP_addr field may indicate the source IPaddress of the IP datagram including the component data of thecorresponding service when the value of the source_IP_address_flag is 1.The dest_IP_addr field may indicate the destination IP address of the IPdatagram including the component data of the corresponding service. Thedest_UDP_port field may indicate the UDP port number of the IP datagramthat contains the component data of the corresponding service. TheLSID_DP field may represent a data pipe identifier of the physical layercarrying signaling including detailed information about the transportsession. Here, the signaling including the detailed information aboutthe transport session may be, for example, an LCT session instancedescription including information on the detailed LCT transport sessionof each ROUTE session in the case of ROUTE.

The service_signaling_flag field may indicate whether the transportsession transmits service signaling. If the value of theservice_signaling_flag value is 1, it may indicate that there is a DPincluding service signaling. The signaling_data_version field mayindicate a change in the associated service signaling data. Each timethe service signaling data changes, the field may be incremented by 1.The receiver may use the signaling_data_version field to detect changesin the signaling associated with the service.

The signaling_DP field may indicate the data pipe identifier of thephysical layer carrying the service signaling. The Transport sessiondescriptors field may contain descriptors at the transport sessionlevel. Each descriptor is extensible, and each descriptor may include anum_descriptors field. Each descriptor may include as many descriptorloops as the value indicated by the num_descriptors field.

The Transport session descriptors field may contain descriptors at thetransport session level. The service descriptors field may includeservice level descriptors. The Partition descriptors field may include apartition level descriptor, and one partition may indicate a part of abroadcast stream used by one broadcaster or the like. The FIC sessiondescriptors field may contain FIC level descriptors. According to anembodiment, each of the fields included in the FIC described above maybe included in a table other than the FIC and transmitted together witha broadcast signal.

FIG. 113 illustrates a method for transmitting FIC-based signalingaccording to another embodiment of the present invention. Theabove-mentioned FIC-based signaling may be delivered as shown in thefigure.

The FIC-based signaling may be referred to as service acquisitioninformation or service acquisition signaling. As shown in the figure,the physical layer signaling may include a field for service acquisitioninformation. The field for the service acquisition information mayinform the receiver of whether the service acquisition information (FIC)is parsed. The receiver parses the service acquisition information andmay check whether the data of the service signaling is changed throughthe service_data_version information. When the service signaling data ischanged, the broadcast signal receiver may acquire the LSID or LSIDTable including detailed information on the transport session using theLSID_DP field through the DP identified from the LSID_DP field. Inaddition, the receiver may recognize change of the signaling data usinginformation such as service_signaling_flag, signaling_data_version,signaling_DP, etc., and acquire the signaling data through the DPidentified from the signaling_DP.

That is, the signaling method of the next generation broadcast systemincludes a procedure of signaling whether the physical layer signalingparses the service acquisition information, and the service acquisitioninformation signals the location of the detailed information about thetransport session to check the detailed information about the transportsession. Here, the detailed information about the transport session mayinclude an MPD transport table, an application signaling table, atransport session descriptor (LSID), and/or a component mapping table(CMT), and each detail of the transmission session may be delivered bydifferent examples.

FIG. 114 is a diagram illustrating a service signaling message format ofa next generation broadcast system according to an embodiment of thepresent invention. In this specification, the service signaling messagemay be referred to as signaling data or service layer signalingincluding detailed information on services and the like. The servicesignaling message may include a signaling message header and a signalingmessage. The signaling message may be expressed in binary or XML format.It may be sent in an IP datagram or a payload of application layertransport packets (e.g., ROUTE or MMTP).

The syntax of the signaling message header may be as follows, which maybe represented in other formats such as XML. The Signaling messageheader may include the following fields. The signaling_id field mayindicate an identifier of a signaling message. For example, if thesignaling message is in the form of a section, it may indicate the id ofthe signaling table section. The signaling_length field may indicate thelength of the included signaling message. The signaling_id_extensionfield may indicate extension information about an identifier for thesignaling message.

The signaling_id_extension field together with the signaling_id fieldmay be used as information for identifying the signaling. For example,the signaling_id_extension field may include a protocol version of thesignaling message. The version_number field may indicate the versioninformation of the signaling message. The version_number field may bechanged if the content of the signaling message changes. Thecurrent_next_indicator field may indicate whether the included signalingmessage is currently available.

If the value of this field is “1”, it indicates that the includedsignaling message is currently available. If the value of this field is“0”, it indicates that the signaling message is not currently availableand that a signaling message containing the same signaling id,signaling_id_extension, or fragment_number will be available later. Thefragmentation_indicator field may indicate whether the signaling messagehas been fragmented. If the value of this field is “1”, this mayindicate that the message has been fragmented. This may in turn indicatethat part of the signaling data is included in signaling_message_data(). If the value of this field is “0”, this may indicate that the entiresignaling data is included in signaling_message_data( ). Thepayload_format_indicator field may indicate whether thepayload_format_indicator field currently contains the value ofpayload_format in the signaling message header. If the value of thisfield is “1”, this may indicate that the payload_format value isincluded in the header part of the signaling message. Theexpiration_indicator field may indicate whether the header part of thesignaling message currently contains an expiration value. If the valueof this field is “1”, it may indicate that the expiration value isincluded in the header part of the signaling message. Thefragment_number field may indicate the fragment number of the currentsignaling message when a signaling message transmitted is divided intomultiple fragments. The last_fragment_number field indicates the numberof the fragment containing the last data of the signaling message whenone signaling message is divided into several fragments. Thepayload_format field may indicate the format of the signaling messagedata contained in the payload. For example, the field may indicatebinary, XML, or the like. The expiration field may indicate the validtime of the signaling message included in the payload.

FIG. 115 shows a service signaling table used in a next generationbroadcast system according to an embodiment of the present invention.

In the present invention, the following service signalingtables/messages may be used in the next generation broadcast network andsignal the following information. The information contained in eachtable/message may be individually transmitted in different tables and isnot limited by the illustrated embodiment. In some embodiments, thesignaling information belonging to different tables may be merged intoone table and transmitted. The service mapping table may includeattributes of a service and information related to the service. Theattribute information of the service may include, for example, as an ID,a name, and a category. The information associated with the service mayinclude path information for acquiring the service. The MPD Deliverytable may contain DASH MPD associated with the service/content or pathinformation for acquiring the DASH MPD. The component mapping table maycontain information about components in the service and informationassociated with the components. The component information may includeassociated DASH representation information, and the informationassociated with the component may include path information for acquiringthe component. The LSID table may contain information about a transportsession for transmitting a service/component and the like and aconfiguration of a transport packet. The Initialization Segment Deliverytable may contain Initialization Segment information about the DASHRepresentation associated with the component in the service or a pathfor acquiring the same. The application parameter table may containrelated information such as detailed information about an applicationassociated with a broadcast service and a path for acquiring the same.

These signaling messages/tables may be transmitted over the broadcastnetwork, through a Rapid Information Channel (FIC), a Service SignalingChannel (SSC), or an application layer transport session (for example,ROUTE or MMTP session). Further, the signaling messages/tables may betransmitted over the Internet network (broadband).

FIG. 116 is a diagram illustrating a service mapping table used in anext generation broadcast system according to an embodiment of thepresent invention.

The content described below may be included in a portion of the servicesignaling message following the signaling message header.

The service mapping table may contain information on service mappingsignaling and may be expressed in XML format or binary format. Theservice mapping table, which is one of service signaling, may contain aservice identifier (id), a service type, a service name, a channelnumber, ROUTE session related information, MPD related information, andcomponent signaling location information.

The service identifier may indicate information for identifying theservice and may be expressed by an id attribute. The service typeinformation may indicate the type of the service, and may be expressedby the serviceType attribute. The service name information may indicatethe name of the service, and may be expressed by the serviceNameattribute. The channel number information may indicate a channel numberassociated with the service, and may be expressed by the channelNumberattribute.

The ROUTE session related information may include a sourcelP attribute,a destinationlP attribute, and a destinationPort attribute. The sourcelPattribute may indicate the source address of the IP datagrams containingthe associated data. The destinationlP attribute may indicate thedestination address of the IP datagrams containing the associated data.The destinationPort attribute may indicate the destination port numberof the UDP packet header in the IP datagram containing the associateddata.

The ROUTE session related information may include detailed information(LSID) about the transport sessions, and may include, for example, eachLSID location and delivery mode information for each LSID locationinformation. The detailed information (LSID) about the transportsessions may also include bootstrap information. The bootstrapinformation included in the LSID may include bootstrap information aboutthe LSID according to the delivery mode. The attributes included in thebootstrap information are described in detail below.

The MPD related information may include information about the MPD or MPDsignaling location.

The information about the MPD may include the version attribute andindicate the version of the MPD DT.

The MPDSignalingLocation information may indicate a location wheresignaling associated with the MPD or MPD URL can be acquired. ThedeliveryMode information included in the MPD signaling location mayindicate the delivery mode of the MPD location signaling. TheBootstrapinfo information included in the MPDSignalingLocation mayinclude bootstrap information about the MPD or MPD URL according to thedelivery mode.

The ComponentSignalingLocation information may include a deliveryModeattribute.

The deliveryMode attribute may indicate the delivery mode of thecorresponding component signaling location information. The bootstrapinformation included in the MPDSignalingLocation may include bootstrapinformation of the corresponding component location signaling accordingto the delivery mode.

The bootstrap information may include at least one of the followingattributes depending on the delivery mode.

The sourcelP attribute may indicate the source address of the IPdatagrams containing the associated data. The destinationlP attributemay indicate the destination address of the IP datagrams containing theassociated data. The destinationPort attribute may indicate thedestination port number of the UDP packet header containing theassociated data. The tsi attribute may indicate an identifier for thetransport session carrying transport packets carrying the associateddata. The URL attribute may indicate a URL where the associated data canbe acquired. The packetid may indicate the identifier of transportpackets carrying the associated data.

FIG. 117 shows a service signaling table of a next generation broadcastsystem according to an embodiment of the present invention.

The next generation broadcast system may provide broadcast servicesignaling to allow the receiver to receive broadcast services andcontent. This allows the receiver to acquire relevant signaling if thesignaling data is transmitted over the same Transport session Identifier(TSI). The service signaling table may be represented in a binary formatas shown in the figure and may be represented in other forms such as XMLaccording to an embodiment. The service signaling table may also beencapsulated in the signaling message format described above. Theservice signaling table may contain the following fields. TheSST_portocol_version field may indicate the version of the servicesignaling table. The partition_id field may indicate the identifier ofthe partition. The SST_data_version field may indicate the data versionof the service signaling table. The num_services field may indicate thenumber of at least one service included in the partition. The service_idfield may indicate the identifier of the corresponding service. Theservice_name field may indicate the name of the service.

The MPD_availability field may indicate whether the MPD can be acquiredover the broadcast, cellular network, and/or wife/Ethernet. TheCMT_availability field may indicate whether a Component Mapping Table(CMT) is available over the broadcast, cellular network and/orwife/Ethernet. The ASL_availability field may indicate whether theApplication Signaling Table (AST) is available over the broadcast,cellular network, and/or wife/Ethernet. The DP_ID field may indicate theidentifier of the DP that delivers the MPD, CMT, and/or ASL throughbroadcast. The LCT_IP_address field may indicate the IP address of theLCT channel carrying the MPD, CMT and/or ASL. The LCT_UDP_port field mayindicate the UDP port of the LCT channel carrying the MPD, CMT and/orASL. The LCT_TSI field may indicate a Transport Session Identifier (TSI)of the LCT channel carrying MPD, CMT and/or ASL. The MPD_TOI field mayindicate a Transport Object Identifier of an application transportpacket that carries the MPD when the MPD is delivered through broadcast.The CMT TOI field may indicate a Transport Object Identifier of anapplication transport packet that carries the CMT when the CMT isdelivered through broadcast. The AST_TOI field may indicate a transportobject identifier of an application transport packet that carries theAST when the AST is delivered via broadcast. The MPD_URL field mayindicate URL information for acquiring MPD over broadband.

The CMT_URL field may indicate URL information for acquiring CMT overbroadband. AST_URL Broadband may indicate URL information for acquiringAST.

FIG. 118 is a diagram illustrating a component mapping table used in anext generation broadcast system according to an embodiment of thepresent invention. The content described below may be included in aportion of the service signaling message located after the signalingmessage header. The component mapping table may contain information oncomponent mapping signaling and may be expressed in the XML format orbinary format. The component mapping table, which is one of the servicesignaling, may include the following fields. The Signaling_id field maycontain an identifier indicating that the corresponding table is acomponent mapping table.

The protocol_version field may indicate the protocol version of thecomponent mapping table, such as the component mapping table syntax. TheSignaling_version field may indicate a change in the signaling data ofthe component mapping table. The Service_id field may indicate anidentifier for a service associated with the components.

The Num_component field may indicate the number of components includedin the service.

The Mpd_id field may indicate the DASH MPD identifier associated withthe component. The Period_id field may indicate a DASH period identifierassociated with the component.

The representation_id field may indicate a DASH representationidentifier associated with the component. The Source_IP field mayindicate the source IP address of the IP/UDP datagram containing thecomponent data. The Dest_IP field may indicate a destination IP addressof an IP/UDP datagram including the component data. The port field mayindicate the port number of the IP/UDP datagram containing the componentdata. The tsi field may indicate the identifier of the application layertransport session containing the component data. The DP_id field mayindicate the identifier of a physical layer data pipe carrying thecorresponding component data. With the above information, the CMT maydefine the components associated with each service and inform thereceiver of the location or path where the components can be received.

FIG. 119 illustrates a component mapping table description according toan embodiment of the present invention.

The Component Mapping Table Description may signal information on atransmission path of components included in a broadcast service in anext generation broadcast system. It may be expressed by a bitstream inthe XML format or binary format. The component mapping table descriptionmay include the following elements and attributes. The service_idattribute may indicate the identifier of the service associated with thecomponent. BroadcastComp may indicate one or more components transmittedover the same broadcast stream. BroadcastComp may include at least oneof mpdID, perlD, reptnlD, baseURL, and/or datapipelD. The mpdIDattribute may indicate the DASH MPD identifier associated withBroadcastComp. The perlD attribute may indicate the associated periodidentifier in the corresponding MPD. The reptnlD attribute may indicatethe DASH Representation identifier associated with the component. ThebaseURL attribute may indicate the Base URL associated with the DASHsegment associated with that component.

The datapipelD attribute may indicate the identifier of a data pipethrough which the corresponding component data is transmitted in abroadcast stream.

BBComp may indicate one or more components transmitted over a broadbandnetwork. BBComp may include at least one of mpdID, perlD, reptnlD,and/or baseURL. The mpdID attribute may indicate the DASH MPD identifierassociated with BBComp. The perlD attribute may indicate the associatedperiod identifier in the corresponding MPD. The reptnlD attribute mayindicate the DASH Representation identifier associated with thecomponent. The baseURL attribute may indicate the Base URL associatedwith the DASH segment associated with that component.

The ForeignComp may indicate one or more components transmitted throughanother broadcast stream. The ForeignComp may include at least one ofmpdID, perlD, reptnlD, baseURL, transportStreamlD, sourcelPAddr,destlPAddr, and/or destUDPPort.

The mpdID attribute may indicate the DASH MPD identifier associated withForeignComp.

The perlD attribute may indicate the associated period identifier in thecorresponding MPD. The reptnlD attribute may indicate the DASHRepresentation identifier associated with the component.

The baseURL attribute may indicate the base URL of the DASH segmentassociated with the component. The transportStreamlD attribute mayindicate the identifier of the broadcast stream containing the componentdata. The sourcelPAddr attribute may indicate the source IP address ofthe IP datagram containing the component data. The destlPAddr attributemay indicate the destination IP address of the IP datagram containingthe component data.

The destUDPPort attribute may indicate the destination UDP port numberof the IP datagram containing the component data. The datapipelDattribute may indicate the identifier of a data pipe through which thecorresponding component data is transmitted in the broadcast stream. TheComponent Mapping Description may be encapsulated in a single XML fileor in the signaling message format proposed above. As shown in the lowerpart of FIG. 70, the Signaling message header may take the formdescribed above, and the component message description or a part thereofmay be included in the service message part. With the above information,the CMT may define the components associated with each service andinform the receiver of the location or path where information related tothe components can be received.

FIG. 120 shows syntax of a component mapping table of a next generationbroadcast system according to an embodiment of the present invention.

The next generation broadcast system may signal the component mappingtable (CMT) to allow the receiver to acquire the components of thebroadcast service. The CMT may be expressed in other formats such as thebinary format or XML format and may be encapsulated in the signalingmessage format described above. The CMT may contain the followingfields. The CMT_portocol_version field may indicate the version of thestructure of the Component Mapping Table (CMT). The service_id field mayindicate an identifier of a service related to a component locationprovided by the corresponding CMT. The CMT_data_version field mayindicate a data version of the corresponding CMT. Thenum_broadcast_streams field may indicate the number of broadcast streamsincluding at least one component associated with the service. The TSIDfield may indicate the transport session identifier of the broadcaststream. The num_partitions field may indicate the number of partitionsof the broadcast stream including at least one component associated withthe service. The CMT may include a plurality of partitions. Thepartition_id field may indicate the identifier of the partition. Thenum_data_pipes field may indicate the number of data pipes in thepartition that includes at least one component associated with theservice. The DP_ID field may indicate the identifier of each data pipe.The num_ROUTE_sessions field may indicate the number of transportsessions (e.g., ROUTE sessions) included in each datapipe. Each datapipe may include at least one component associated with the service. TheIP_address field may indicate the IP address of each transport session.The UDP_port field may indicate the UDP port of each transport session.The num_LCT_channels field may indicate the number of LCT channels inthe transport session including the component associated with theservice. The LCT_TSI field may indicate a Transport Session Identifier(TSI). The Representation ID field may indicate the identifier of theDASH Representation carried by the corresponding LCT channel. Accordingto an embodiment, the CMT may further include an MPD id field and aPeriod id field. In this case, a globally unique ID may be acquired bycombining MPD id, Period id, and Representation id. The Internetavailability field may be an identifier that indicates whether theRepresentation can be received over the Internet or broadband.

The num_internet_only_reptns field may indicate the number ofRepresentations that may be received only over the Internet orbroadband. The Representation_ID field may indicate an identifier of aDASH Representation that can be received only over the Internet orbroadband within a loop of num_internet_only_reptns. As described above,according to embodiments, a globally unique identifier may be configuredby combining MPD id, Period id, and Representation id. With the aboveinformation, the CMT may define the components associated with eachservice and inform the receiver of the location or path where thecomponents can be received.

FIG. 121 illustrates a method for delivering signaling associated witheach service over a broadband network in a next generation broadcastsystem according to an embodiment of the present invention.

The next generation broadcast system may transmit signaling related tothe service to the receiver over the broadband network or the like. Thenext generation broadcast system may transmit signaling to the receiverthrough a broadband network or the like using URL Signaling TableDescription. It may be represented in other formats such as XML orbinary. The URL Signaling Table Description may include the followingattributes. The service_id attribute may indicate the identifier of theservice associated with the signaling. The mpdURL attribute may indicatethe URL of the broadband MPD. The cstURL attribute may indicate the URLof the broadband CMT. The CMT may contain information on the componentdata acquisition path in the broadcast service. The astURL attribute mayindicate the URL of the broadband AST. The AST may include informationabout an application associated with the broadcast service. The receivermay receive the description and receive the corresponding signalingbased on the URL for each signaling. The URL Signaling Table Descriptionmay be encapsulated in a single XML file or in the signaling messageformat proposed above. As shown in the lower part of the figure, thesignaling message header may conform to the form proposed above, and theheader may include a URL Signaling Table Description or a part thereof

FIG. 122 illustrates a method for signaling MPD in a next generationbroadcast system according to an embodiment of the present invention.

The signaling message for the MPD of the broadcast service available inthe next generation broadcast network may include a signaling messageheader and a signaling message as shown in the upper part of the figure.The Signaling message header may conform to the above-described format,and the MPD delivery table information may include the followinginformation. The Signaling_id information may identify that thecorresponding signaling message is a signaling message that includes theMPD or path information for acquiring the MPD. The protocol_versioninformation may indicate the protocol version of the MPD delivery table,such as the syntax of the signaling message.

The Signaling_version information may indicate a change in the signalingdata of the MPD delivery table. The Service_id information may indicatea service identifier associated with the signaling information. TheMpd_id information may indicate the identifier of the DASH MPDassociated with the signaling message. The MPD_version information mayrepresent version information indicating a change of the correspondingMPD or the like. The Delivery_mode information may indicate whether thesignaling message includes the corresponding MPD or whether the MPD istransmitted through another path.

The MPD_data( ) information may include the MPD data if the signalingmessage includes the MPD. The MPD_path information may includeinformation on a path for acquiring the MPD. For example, a path mayrepresent a URL, etc.

The MPD delivery table description may contain the followinginformation.

The service_id attribute may indicate the identifier of the serviceassociated with the signaling. The MPD_id attribute may indicate theidentifier of the MPD. MPD_version may indicate version information thatmay indicate the MPD change information. The MPD_URL attribute mayinclude URL information for acquiring an MPD. The MPD element may alsoinclude MPD information. The MPD Delivery Table Description may beencapsulated in a single XML file or in the signaling message formatproposed above. That is, the signaling message header may conform to thepreviously proposed format, followed by an MPD Delivery TableDescription or a part thereof.

FIG. 123 shows syntax of an MPD delivery table of a next generationbroadcast system according to an embodiment of the present invention.

The information of the MPD delivery table or a part thereof may beincluded after the signaling message header, and the information of theMPD delivery table may contain the following fields. The service_idfield may indicate the identifier of an associated broadcast service.The MPD_id_length field may indicate the length of subsequentMPD_id_bytes( ).

The MPD id bytes field may indicate the identifier of the MPD fileincluded in the signaling message. The MPD_version field may indicateversion information such as a change in data of the MPD. TheMPD_URL_availabilty field may indicate whether the URL information ofthe MPD exists in the corresponding signaling table/message. TheMPD_data_availabilty field may indicate whether the MPD is included inthe signaling table/message. If the value of this field is ‘1’, this mayindicate that the MPD is included in the signaling table/message.

The MPD_URL_length_field may indicate the length of subsequentMPD_URL_bytes( ).

The MPD_URL_bytes field may indicate the MPD URL included in thesignaling message.

The MPD_coding field may indicate the encoding scheme of the MPD fileincluded in the signaling message. As shown in the lower part of thefigure, the MPD_coding field may indicate that MPD files are encoded indifferent encoding schemes according to the values. For example, if thevalue of the MPD_coding field is ‘0x00’, this may indicate that the MPDfile includes the MPD file. If the value of the field is ‘0x01’, thismay indicate that MPD file compressed by gzip is included. For example,if the MPD compressed by gzip is divided into a plurality ofmessages/tables, the corresponding MPD_bytes( ) may be concatenated andungziped. The MPD_byte_length field may indicate the followingMPD_bytes( ) length. The MPD_bytes field may contain the actual data ofthe MPD file included in the signaling message according to the encodingscheme specified in MPD_coding. The next generation broadcast systemallows the receiver to receive or acquire the MPD associated with theservice through the MPD delivery table including the fields describedabove.

FIG. 124 shows a description of a transmission session instance of anext generation broadcast system according to an embodiment of thepresent invention. When the application layer transmission method isReal-Time Object Delivery over Unidirectional Transport (ROUTE), a ROUTEsession may include one or more Layered Coding Transport (LCT) sessions.The details of one or more transport sessions may be signaled through atransport session instance description. The transport session instancedescriptor may be referred to as LCT Session Instance Description (LSID)if it is ROUTE. In particular, the transport session instancedescription may define what is delivered by each LCT transport sessionconstituting the ROUTE session. Each transport session may be uniquelyidentified by the Transport Session Identifier (TSI). The transportsession identifier may be included in the LCT header. The transportsession instance description may describe all transport sessions thatare transmitted through the session. For example, the LSID may describea mode LCT session carried by a ROUTE session. The transport sessioninstance description may be delivered through the same ROUTE session asthe transport sessions, or may be delivered through different ROUTEsessions or unicast.

When delivered in the same ROUTE session, the transport session instancedescription may be transmitted in the transport session with a specifiedtransport session identifier (TSI) 0. Other objects referenced in thetransport session instance description may also be delivered with TSI=0,but may have a TOI value different from the transport session instancedescription. Alternatively, it may be delivered in a separate sessionwith TSI≠0. The transport session instance description may be updatedusing at least one of the version number, validity information, andexpiration information. The transport session instance description maybe represented in a bitstream or the like in addition to the illustratedformat.

The transport session instance description may include a versionattribute, a validFrom attribute, an expiration attribute, and mayinclude TSI attributes and SourceFlow and RepairFlow information foreach transport session. The version attribute may indicate the versioninformation about the corresponding transport session instancedescription, and the version information may be incremented each timethe content is updated. The transfer session instance description withthe highest version number may indicate the most recent valid version.The validFrom attribute may indicate when the transfer session instancedescription begins to be valid. The validFrom attribute may not beincluded in the transport session instance description according to anembodiment. This indicates that the transport session instancedescription is valid immediately upon receiving the description. Theexpiration attribute may indicate when the transfer session instancedescription expires.

The expiration attribute may not be included in the transport sessioninstance description according to the embodiment. This indicates thatthe transport session instance description is continuously valid. If atransport session instance description with an expiration attribute isreceived, expiration may conform to the expiration attribute. The TSIattribute may indicate a transport session identifier, and theSourceFlow element provides information about the source flow to betransmitted to the TSI, the details of which will be described below.The RepairFlow element may provide information about the repair flowsent to the corresponding TSI.

FIG. 125 shows a SourceFlow element of a next generation broadcastsystem according to an embodiment of the present invention.

The source flow element may include an EFDT element, an idRef attribute,a realtime attribute, a minBufferSize attribute, an ApplicationIdentifier element, and a PayloadFormat element. The EFDT element mayinclude detailed information of the file delivery data. An EFDT mayindicate an extended File Delivery Table (FDT) instance, described inmore detail below. The idRef attribute may indicate the identifier ofthe EFDT and may be represented as a URI by the corresponding transportsession. The realtime attribute may indicate that the corresponding LCTpackets include an extension header. The extension header may include atimestamp indicating the presentation time of the delivery object. TheminBufferSize attribute may define the maximum amount of data needed tobe stored in the receiver. The Application Identifier element mayprovide additional information that may be mapped to an applicationcarried by that transport session. For example, the Representation ID ofthe DASH content or the Adaptation Set parameter of the DASHrepresentation for selecting a transport session for rendering may beprovided as additional information. The PayloadFormat element may definethe payload format of a ROUTE packet carrying an object of the sourceflow. The PayloadFormat element may include a codePoint attribute, adeliveryObjectFormat attribute, a fragmentation attribute, adeliveryOrder attribute, a sourceFecPayloadlD attribute, and/or aFECParameters element. The codePoint attribute may define the structureof the packet with the code point value used in the payload. This mayindicate the value of the CP field in the LCT header.

The deliveryObjectFormat attribute may indicate the payload format ofthe delivery object. The fragmentation attribute may definefragmentation rules when an object to be transmitted is divided into oneor more transport packets. The deliveryOrder attribute may indicate theorder of transmission of the content of each transport packet carryingone transport object. The sourceFecPayloadlD attribute may define theformat of the source FEC payload identifier. The FECParameters elementmay define FEC parameters. This may include FEC encoding id and instanceid.

FIG. 126 shows an EFDT of a next generation broadcast system accordingto an embodiment of the present invention.

The EFDT may include detailed information of the file delivery data. TheEFDT may include an idRef attribute, a version attribute, amaxExpiresDelta attribute, a maxTransportSize attribute, and aFileTemplate element. The idRef attribute may indicate the identifier ofthe EFDT. The version attribute may indicate the version of the EFDTinstance descriptor. This attribute may be incremented by 1 when EFDT isupdated. It may indicate that the EFDT having the highest version numberamong the received EFDTs is the currently valid version. ThemaxExpiresDelta attribute may indicate the maximum expiry time of theobject after the first packet associated with the object is sent.

The maxTransportSize attribute may indicate the maximum transmissionsize of the object described by the EFDT. For the FileTemplate element,the file URL or file template of the body part may be specified.

The transport session instance descriptor (LSID) element may betransmitted by the Transport Session Instance Descriptor Table (LSIDTable) at the bottom of the figure. The LSID table may be transmitted bythe above-described signaling message, which may be divided into asignaling message header and a signaling message data part. Thesignaling message data part may include a transport session instancedescriptor (LSID) or a part thereof. The signaling message data mayinclude a Transport Session Instance Descriptor (LSID) Table and mayinclude the following fields. The Signaling id field may indicateidentifier information indicating that the signaling table includes atransport session instance descriptor (LSID). The protocol version fieldmay indicate a protocol version of the signaling, such as a signalingsyntax that includes a transport session instance descriptor (LSID). TheSignaling version field may indicate a change in signaling data,including a transport session instance descriptor (LSID). In addition,the transport session instance descriptor table may further include thecontent of the LSID element described above.

FIG. 127 shows a method for transmitting an ISDT used by a nextgeneration broadcast system according to an embodiment of the presentinvention.

The next generation broadcast system may transmit signaling informationfor the initialization segment of the DASH Representation associatedwith the component in the broadcast service by transmitting theInitialization Segment Delivery Table (ISDT). A signaling message forthe initialization segment of a DASH Representation associated with acomponent in a broadcast service may include a header and data. Thesignaling message header may conform to the above-described format, andthe signaling message data may include initialization segment deliveryinformation or a part thereof

The initialization segment delivery information may include thefollowing information.

The Signaling_id information may identify the initialization segment ora signaling message including path information. The protocol_versioninformation may indicate the protocol version of the initializationsegment delivery table, such as the syntax of the correspondingsignaling message. The Sequence_number information may indicate theidentifier for an instance of the initialization segment delivery table.The Signaling_version information may indicate a change in the signalingdata of the initialization segment delivery table. The Service_idinformation may identify the service associated with the component.

The Mpd_id information may indicate an associated DASH MPD identifierassociated with the component.

The period_id information may indicate an associated DASH Periodidentifier associated with the component. The representation_idinformation may indicate a DASH representation identifier associatedwith the component. The initialization_segment_version information maybe version information indicating a change of the corresponding MPD orthe like. The Delivery_mode information may indicate information aboutwhether the initialization segment is included or is transmitted throughanother route. Initialization_segment_data( ) information may containthe initialization segment data itself. The initialization segment pathinformation may include information on a path for acquiring aninitialization segment, such as a URL for an initialization segment.Through the ISDT, the receiver may receive information about theInitialization segment of the DASH Representation associated with thecomponent.

FIG. 128 shows a delivery structure of a signaling message of a nextgeneration broadcast system according to an embodiment of the presentinvention.

The above signaling data may be communicated as shown in the figure ifit is sent based on an application layer transport, for example, ROUTE.That is, a part signaling may be transmitted through a fast informationchannel in order to support rapid service scan. And a part of thesignaling may be transmitted over a specific transport session and mayalso be delivered mixed with the component data.

The signaling information for supporting the rapid service scan andacquisition may be received on a channel separate from the transportsession. Here, the separate channel may mean a separate data pipe (DP).Further, detailed information about the service may be received througha separately designated transport session. The transport session mayhave a value of TSI=0. The information delivered through the transportsession designated herein may include an MPD delivery table, anapplication signaling table, a transport session instance descriptiontable, and/or a component mapping table. In addition, a part ofsignaling information may be delivered in the transport session alongwith the component data. For example, an initialization segment deliverytable may be delivered with the component data.

The lower part of the figure shows an embodiment of acquiring abroadcast service in a next generation broadcast network. The receivermay tune the broadcast and acquire and parse information for rapidservice scanning and acquisition when the service is selected. Thelocation of the service layer signaling or transport session instancedescription (e.g., LSID) is then determined from the information forrapid service scan and acquisition to acquire and parse the description.In addition, the receiver may identify the transport session includingthe signaling, from which it may acquire and parse the signaling table,and determine a desired component. Through this process, the desiredcomponent may be presented. That is, the broadcast service may beprovided to the user by acquiring information about the transportsession from the information for rapid service scan and acquisition,checking the position of the desired component from the informationabout the transport session, and reproducing the component.

Hybrid broadcast can provide services through applications.Specifically, a broadcaster may provide broadcast content relatedinformation through applications. For example, the broadcaster mayprovide an application through which products used by actors inbroadcast content can be purchased. For such an application, a broadcasttransmission device 10 may transmit application signaling informationfor signaling an application. The application signaling information mayinclude at least one of a trigger for triggering an application actionand triggering application information for signaling information about atriggered application. This will be described with reference to theattached drawings.

The triggering application information may include additionalinformation necessary to execute the application. Specifically, thetriggering application information may include application properties.Further, the triggering application information may include informationon a position at which a file included in the application can bedownloaded and received. In addition, the triggering applicationinformation may include information on a position at which an NRTcontent item used by the application can be received.

Furthermore, the triggering application information may signallife-cycle variation of the application. Specifically, the lift-cycle ofthe application may include at least one of preparing, executing,terminating and suspending. For example, execution of the applicationmay be prepared through the preparing state. In addition, theapplication may be executed in the preparing state. The application mayenter the terminating state by terminating execution thereof. Further,execution of the application may be suspended in the suspending state.

The triggering application information may include an action to beexecuted by the application. Specifically, the triggering applicationinformation may include data necessary to execute an application action.

The triggering application information may include media time.Specifically, the triggering application information may include mediatime of content synchronized with the application.

Specifically, the broadcast transmission device 10 may transmit atrigger for triggering an application action. Further, a broadcastreception device 100 may cause the application to execute a specificaction on the basis of the trigger. Specifically, the trigger may havethe format below.

The trigger may include a domain part indicating a registered Internetdomain name. In addition, the trigger may include a directory path partindicating a random character string for identifying a directory path ofthe domain name indicated by the domain part. Further, the trigger mayinclude a parameter part indicating a parameter for triggering theapplication. Specifically, the trigger may have the following format.

<domain name part>/<directory path>[?<parameter>]

Here, the domain name part and the directory path part may be mandatoryparts essentially included in the trigger. In addition, the parameterpart is an optional part optionally included in the trigger. Theparameter part may include at least one of an event ID for identifyingan event, an application ID for identifying a target application of thetrigger, and a timing value indicating a time when an event isperformed. Furthermore, the parameter part may include content mediatime. Moreover, the parameter part may include a content ID foridentifying content reproduced by the broadcast reception device 100. Inaddition, the parameter part may include spread information forspreading triggering application information request traffic of thebroadcast reception device 100. Further, the parameter set may includeversion information indicating a version of triggering applicationinformation related to the trigger.

Specifically, the parameter part may include at least one of thefollowing strings.

<media time>

<media time> and <spread>

<media time> and <version>

<media time> and <version> and <spread>

<event time>

<event time> and <spread>

<event time> and <version>

<event time> and <version> and <spread>

<event time> may include an event ID for identifying an event. Here, theevent may refer to execution of an action by the application accordingto the trigger. Here, the event ID may be designated by “e=”. Inaddition, the event ID may include two or three decimals following “e=”.Here, the decimals may be discriminated using a period (“.”). Further,<event time> may include an application ID for identifying theapplication that is a target of the trigger. Here, the application maybe called a triggered declarative object (TDO). The application ID maybe matched to an application ID of the triggering applicationinformation. Accordingly, the broadcast reception device 100 may acquireinformation about the application that is a target of the trigger fromthe triggering application information on the basis of the applicationID of the trigger. Here, the triggering application information may be aTDO parameter table (TPT) for signaling trigger information. Inaddition, the parameter part may include a data ID for identifying adata element used for the event. Further, the parameter part may includea timing value indicating a time when the event is performed. Here, thetiming value may be designated by “t=”. In a specific embodiment, thetiming value may be designated as a hexadecimal represented by one toeight characters following “t=”. When <event time> does not include thetiming value, the trigger may trigger the application to execute theevent at the trigger reception time.

<media time> may include media time of content. Specifically, <mediatime> may indicate a media time stamp of content synchronized with theapplication triggered by the trigger. Specifically, the media time maybe designated by “m=”. The media time may be designated as a hexadecimalrepresented by one to eight characters following “m=”. Further, <mediatime> may be denoted in milliseconds. In addition, <media time> mayindicate a content ID for identifying content currently reproduced bythe broadcast reception device 100. The content ID may be designated by“c=”. Specifically, when an application is executed according to adirect execution model, <media time> may include the content ID. In aspecific embodiment, the broadcast reception device 100 may receive atime base trigger delivering reference time for applicationsynchronization and extract the content ID from the time base trigger.Here, the broadcast reception device 100 may receive an interactiveservice for content currently reproduced thereby by transmitting thecontent ID to a server for the interactive service.

<version> may include version information indicating a version of thetriggering application information related to the trigger. Here, thetriggering application information may be a TPT. Specifically, theversion information may be designated by “v=”. Further, the versioninformation may be designated by a decimal represented by one to threecharacters following “v=”. The broadcast reception device 100 mayextract the version information from the trigger and acquire thetriggering application information on the basis of the versioninformation.

<spread> may include spread information that is a criterion forcalculation of a time for which the broadcast reception device 100 needsto wait to request that a server providing the application signalinginformation provide the triggering application information.Specifically, the broadcast reception device 100 may calculate a randomvalue on the basis of the time indicated by the spread information, waitfor the random value and then request the triggering applicationinformation. The spread information may be designated by “s=”.Specifically, the spread information may be designated by a decimalrepresented by one to three characters following “s=”. The broadcastreception device 100 can request the triggering application informationthrough the spread information to prevent traffic of the serverproviding the triggering application information from being concentratedon the trigger reception time.

<others> may include information other than the aforementionedparameters. The broadcast reception device 100 may ignore parametersthat are not recognizable.

A trigger including a media time of content may be called a time basetrigger. Specifically, the time base trigger may deliver a media timestamp of content reproduced by the broadcast reception device 100. Inaddition, the broadcast reception device 100 may generate a referencetime for synchronization between an application action and content onthe basis of the time base trigger.

A trigger including an event time may be called an activation triggerbecause the activation trigger designates a time when the correspondingevent is performed. The broadcast reception device 100 may perform atriggered operation on the basis of the event time of the trigger.Specifically, the broadcast reception device 100 may extract the eventtime from the trigger and perform an operation triggered at the eventtime.

In addition, the parameter part of the trigger may include not only atiming value indicating a time when an event starts to be performed butalso a timing value indicating a time when the event is ended. Further,when the broadcast reception device 100 receives the trigger after anevent start time and before an event end time, the broadcast receptiondevice 100 may perform the event triggered by the trigger. Specifically,the parameter part may include <event start time> and <event end time>.

<event start time> may include a timing value indicating a time when anevent starts to be performed. The timing value may be designated by“st=” following “e=” identifying the event.

<event end time> may include a timing value indicating a time when theevent is ended. The timing value may be designated by “et=” following“e=” identifying the event.

FIG. 129 illustrates a trigger according to the aforementioned triggersyntax.

The trigger syntax according to another detailed embodiment may have atime text format indicated at a predetermined time. In detail, the timedtext may be a closed caption.

FIG. 130 illustrates the syntax of triggering application informationaccording to an embodiment of the present invention.

As described above, the triggering application information may bereferred to as TPT. The triggering application information may signal acorresponding application corresponding to all program segments or someprogram segments according to time. In this case, the program segmentmay indicate a time period including a program.

The triggering application information may include protocol versioninformation indicating a protocol version of triggering applicationinformation. In detail, the triggering application information mayinclude major protocol version information indicating main versioninformation of a protocol and minor protocol version informationindicating additional version information of a protocol. In this case,the major protocol version information may correspond to a 3-bitinteger. When the broadcast receiving apparatus 100 is not capable ofsupporting any one of the major protocol version information and theminor protocol information, the broadcast receiving apparatus 100 maydisregard the triggering application information. The major protocolversion information may be referred to as MajorProtocolVersion. Theminor protocol version information may be referred to asMinorProtocolVersion. In a detailed embodiment, the major protocolversion information may be a 3-bit element. The minor protocol versioninformation may be a 4-bit element.

The triggering application information may include an identifier foridentifying the triggering application information. In detail, thetriggering application information may be an identifier for identifyinga program segment. In a detailed embodiment, the identifier foridentifying the program segment may be generated by combining a domainname and a program ID. For example, the identifier may be domainname/program id.

The triggering application information may include version informationfor indicating an update history of the triggering applicationinformation. A value of the version information may be changed wheneverthe triggering application information is changed. The broadcastreceiving apparatus 100 may determine whether detailed informationincluded in the triggering application information is extracted based onthe version information. In a detailed embodiment, the versioninformation may be referred to as tptVersion. In a detailed embodiment,the version information may be an 8-bit element.

The triggering application information may include expiration timeinformation indicating expiration date and time of the triggeringapplication information. In detail, the broadcast receiving apparatus100 may store the triggering application information and reuse thetriggering application information prior to the expiration date and timeindicated by the expiration time information. In a detailed embodiment,the expiration time information may be referred to as expirationDate. Ina detailed embodiment, the expiration time information may be a 16-bitelement.

The triggering application information may include time intervalinformation indicating a time interval for checking update of thetriggering application information. In detail, the broadcast receivingapparatus 100 may update the triggering application information at atime interval indicated by the time interval information. In a detailedembodiment, the time interval information may be referred to asupdatingTime. In a detailed embodiment, the time interval informationmay be a 16-bit integer.

The triggering application information may include a service identifierfor identifying a service including an application. In a detailedembodiment, the service identifier may indicate an identifier of an NRTservice defined in the ATSC standard. In a detailed embodiment, theservice identifier may be referred to as serviceId. In a detailedembodiment, the service identifier may be a 16-bit integer.

The triggering application information may include a base URL indicatinga basic address of a URL included in the application information. In adetailed embodiment, the base URL may be referred to as baseURL.

The triggering application information may include capabilityinformation indicating capability required for presentation of anapplication signaled by the application information. The capabilityinformation may comply with a definition of capabilities descriptordefined in the ATSC standard. In a detailed embodiment, the capabilityinformation may be referred to as capabilities.

The triggering application information may include live triggerinformation that is generated in real time and transmitted via theInternet together with transmission of content. In detail, the livetrigger information may include a URL of a server for transmitting alive trigger. The live trigger information may include a polling periodwhen a live trigger is transmitted using a polling method. In a detailedembodiment, the live trigger information may be referred to asLiveTrigger. In addition, a URL of a server for transmitting the livetrigger may be referred to as a URL. In addition, the polling period maybe referred to as pollPeriod.

The triggering application information may include information on anapplication. The application information may include detailedinformation on an application as a sub-element. In a detailedembodiment, the application information may be referred to as TDO.

The application information may include an application identifier foridentifying an application. In a detailed embodiment, the applicationidentifier may be referred to as applD. In a detailed embodiment, theapplication identifier may be a 16-bit element.

The application information may include application type informationindicating a type of an application. In a detailed embodiment, when avalue of the application type information is 1, the application typeinformation may indicate TDO. In a detailed embodiment, the applicationtype information may be referred to as appType. In a detailedembodiment, application type information may be a 16-bit element.

The application information may include application name informationindicating a name of an application. In a detailed embodiment, theapplication name information may be referred to as appName.

The application information may include a global identifier for globallyuniquely identifying an application. The global identifier may be usedto indicate the same application as in other application information aswell as corresponding triggering application information. In a detailedembodiment, the global identifier may be referred to as globalID.

The application information may include application version informationthat is version information indicating an update history of anapplication. In a detailed embodiment, the application versioninformation may be referred to as appVersion. In a detailed embodiment,the appVersion may be an 8-bit element.

The application information may include cookie space informationindicating a size of a persistent storage space required to execute anapplication by the broadcast receiving apparatus 100. The cookie spaceinformation may indicate a size of a storage space required to executean application in kilobytes. In a detailed embodiment, the cookie spaceinformation may be referred to as cookieSpace. In a detailed embodiment,the cookie space information may be an 8-bit element.

The application information may include use frequency informationindicating a use frequency of an application. The use frequencyinformation may indicate at least one of only once, every time, everyday, every week, and every month. In a detailed embodiment, the usefrequency information may have a value of 1 to 16. In a detailedembodiment, the use frequency information may be referred to asfrequency0fUse.

The application information may include expiration time informationindicating expiration time and date of an application. In a detailedembodiment, expiration time information may be referred to asexpireDate.

The application information may include test application informationindicating an application for test broadcast. The broadcast receivingapparatus 100 may disregard an application for test broadcast based ontest application information. In a detailed embodiment, the testapplication information may be referred to as testTDO. In a detailedembodiment, the test application information may be a Boolean element.

The application information may include Internet available informationindicating that an application is capable of being received through theInternet. In a detailed embodiment, the Internet available informationmay be referred to as availablelnternet. In a detailed embodiment, theInternet available information may be a Boolean element.

The application information may include broadcast available informationindicating that an application is capable of being received through abroadcast network. In a detailed embodiment, the broadcast availableinformation may be referred to as availableBroadcast. In a detailedembodiment, the broadcast available information may be a Booleanelement.

The application information may include URL information for identifyinga file as a part of an application. In a detailed embodiment, theapplication information may be referred to as URL.

The URL information may include entry information indicating whether acorresponding file is an entry file. In detail, the entry file mayindicate a file to be first executed in order to execute a correspondingapplication.

The application information may include capability informationindicating necessary capability information required for presentation ofan application. In a detailed embodiment, the capability information maybe referred to as Capabilities.

The application information may include application boundary informationindicating a boundary of an application. In a detailed embodiment, theapplication boundary information may be referred to asApplicationBoundary.

The application boundary information may include origin URL informationrequired to add a boundary of an application. The origin URL informationmay be referred to as originURL.

The application information may include content item informationindicating information on a content item used by an application. Thecontent item information may include detailed information content item.In a detailed embodiment, the content item information may be referredto as contentltem.

The content item may include URL information for identifying a file as apart of a corresponding content item. The URL information may bereferred to as URL.

The URL information may include entry information indicating whether acorresponding file is an entry content file. In detail, the entry filemay indicate a file to be first executed in order to execute acorresponding content item. In a detailed embodiment, the entryinformation may be referred to as entry.

The content item information may include update information indicatingwhether a corresponding content item is capable of being updated. Indetail, the update information may indicate whether a content itemincludes a fixed file or the content item is real time data feed. In adetailed embodiment, the update information may be referred to asupdateAvail. The update information may be a Boolean element.

The content item information may include a polling period when thecontent item is updated and when whether a file included in the contentitem is updated is checked using a polling method. In detail, thebroadcast receiving apparatus 100 may check whether the content item isupdated based on the polling period. The polling period may be referredto as pollPeriod.

The content item information may include size information indicating asize of the content item. In a detailed embodiment, the size informationmay indicate a size of the content item in a kilo byte. The sizeinformation may be referred to as a size.

The content item information may include Internet available informationindicating that the content item is capable of being received throughthe Internet. In a detailed embodiment, the Internet availableinformation may be referred to as availablelnternet. In a detailedembodiment, the Internet available information may be a Boolean element.

The content item information may include broadcast available informationindicating that the content item is capable of being received through abroadcast network. In a detailed embodiment, the broadcast availableinformation may be referred to as availableBroadcast. In a detailedembodiment, the broadcast available information may be a Booleanelement.

The application information may include event information indicatinginformation on an event of an application. In a detailed embodiment, theevent information may be referred to as event.

The event information may include an event identifier for identifying anevent. In detail, the event identifier may uniquely identify an eventwithin a corresponding application range. In a detailed embodiment, theevent identifier may be referred to as eventlD. In a detailedembodiment, the event identifier may be a 16-bit element.

The event information may include action information indicating anoperation of an event. In detail, the event information may includepreparing, execution, termination or kill, and/or suspending. In adetailed embodiment, the action information may be referred to as anaction.

The event information may include destination information indicatingtarget information targeted by an application. The destinationinformation may indicate that an application is used only for a primarydevice for receiving a broadcast signal. The destination information mayindicate that an application is used only for one or more associateddevices that are operatively associated with a primary device forreceiving a broadcast signal. The destination information may indicatethat an application is used for both a primary device and an associateddevice. In a detailed embodiment, the destination information may bereferred to as destination.

The event information may include diffusion information for diffusion ofa triggering application information request. In detail, the broadcastreceiving apparatus 100 may calculate a random value based on diffusioninformation, may be on standby by as much as the random value and, thenmay make a request for the triggering application information to aserver. In detail, the broadcast receiving apparatus 100 may be onstandby by as much as a value obtained by multiplying the random valueby 10 ms and then may make a request for the triggering applicationinformation to the server. In a detailed embodiment, the diffusioninformation may be referred to as diffusion. In a detailed embodiment,the diffusion information may be an 8-bit element.

The event information may include data information indicating dataassociated with an event. Each event may have a data element associatedwith an event. In a detailed embodiment, the data information may bereferred to as data.

The data information may include a data identifier for identifying data.The data identifier may be referred to as datalD. The data identifiermay be a 16-bit element.

Transmission of the event of the MPEG-DASH through the MPD will bedescribed below with reference to FIGS. 131 to 132.

FIG. 131 illustrates the syntax of an event stream element including anMPD according to an embodiment of the present invention. FIG. 132illustrates the syntax of an event element of an event stream elementincluded in the MPD according to an embodiment of the present invention.

Presentation time of an event sequence of the MPEG-DASH may be providedat a period level. In detail, the period element of the MPD may includean event stream element indicating information on an event stream. Thebroadcast receiving apparatus 100 may terminate an event whentermination time of a period including an event elapses. In particular,even if an event is started at a boundary time of a period, thebroadcast receiving apparatus 100 may also terminate the event when thetermination time of the period including the event elapses.

The period element may include an event stream element includinginformation on an event stream. In a detailed embodiment, the eventstream element may be referred to as an event stream.

The event stream element may include a format identifier element foridentifying format of a message included in an event. In a detailedembodiment, the format identifier element may be referred to asschemelDUri.

The event stream element may include a value element indicating a valuefor an event stream. In a detailed embodiment, value attribute may bereferred to as a value.

When an event including an event stream is a timed event, the eventstream element may include time scale attribute indicating a time unit.In a detailed embodiment, the time scale attribute may be referred to asa timescale.

The event stream element may specify each event and include an eventelement including a message that is information of the event. In adetailed embodiment, the event element may be referred to as an event.

The event element may include presentation start time attributeindicating presentation start time of an event. In detail, thepresentation start time attribute may indicate relative presentationstart time based on the period start time. When the presentation starttime attribute is not present, a value of the presentation start timemay be 0. In a detailed embodiment, the presentation start timeattribute may be referred to as presentationTime.

The event element may include presentation duration attribute indicatingevent presentation duration. When the presentation duration attribute isnot present, a value of the presentation duration may be unknown. In adetailed embodiment, the presentation duration attribute may be referredto as duration.

The event element may include identifier attribute for identifying anevent. Events with the same content and events with the same attributevalue of an event element may have the same identifier element value.

Transmission of an event of the MPEG-DASH through an inband stream willbe described with reference to FIG. 133.

FIG. 133 illustrates the syntax of an event message box for inband eventsignaling according to an embodiment of the present invention.

The broadcast server 10 may multiplex an event stream of the MPEG-DASHtogether with representation. In detail, the broadcast server 10 maymultiplex the event stream of the MPEG-DASH as a part of a segmenttogether with representation.

The event stream of the MPEG-DASH may be inserted into selectedrepresentation. In a detailed embodiment, the broadcast server 10 mayinsert an event stream into partial representation included in anadaptation set. In another detailed embodiment, the broadcast server 10may insert the event stream into all representation included in theadaptation set.

The inband event stream included in representation may be represented byan inband event stream element included in the adaptation set orrepresentation level. In a detailed embodiment, the inband event streamelement may be referred to as InbandEventStream. In a detailedembodiment, one representation may include a plurality of inband eventstreams. Each of the plurality of inband event streams may berepresented by a separate inband event stream element.

An event message box ‘emsg’ may provide signaling for a general eventrelated to media presentation time. The event message box may signal aspecific operation related to the DASH operation. When a media segmentis encapsulated in the form of ISO BMFF, the media segment may includeone or more event message boxes. The event message box may be positionedprior to a moof box ‘moof’.

A scheme of the event message box may be defined in the MPD. Thebroadcast receiving apparatus 100 may disregard the event message boxwith a scheme that is not defined in the MPD.

The event message box may include a scheme identifier field foridentifying a scheme of the event message box. In a detailed embodiment,the scheme identifier field may be referred to as shceme_id_uri.

The event message box may include a value field indicating a value of anevent. A value of the value field may have a different scheme andmeaning according to a scheme identified according to a schemeidentifier field. In a detailed embodiment, the value field may bereferred to as a value.

The event message box may include a time scale field indicating a unitof time related to the event message box. In detail, the event messagebox may indicate a presentation start time delay field including theevent message box and a time unit of the presentation duration field. Ina detailed embodiment, the time scale field may be referred to astimescale.

The event message box may include a presentation start time delay fieldindicating a degree by which presentation start time of an event isdelayed from an earliest presentation time of a segment. In detail, thebroadcast receiving apparatus 100 may extract earliest presentation timeof a segment from a segment index box ‘sidx’. In this case, thebroadcast receiving apparatus 100 may add time indicated by thepresentation start time delay field to the segment presentation time toacquire event presentation start time. In a detailed embodiment, theevent presentation start time may be referred to aspresentation_time_delta.

The event message box may include an event presentation duration fieldindicating presentation duration of an event. When a value of the eventpresentation duration field is 0xffff, this may indicate that the eventpresentation duration is unknown. In a detailed embodiment, the eventpresentation duration may be referred to as event_duartion.

The event message box may include identifier attribute for identifyingan event. Events with the same content and events with the sameattribute value of the event message box may have the same identifierelement value.

The event message box may include a message data field indicating a bodyof the message box. Data of the message data field may be changedaccording to a scheme of the message box.

Attribute of a trigger may be matched with the event message boxindicating the inband event stream and an element of the MPD indicatingan event stream of the MPEG-DASH and the application signalinginformation may be transmitted, which will be described below.

First, for clarity for distinguishing terms, an event of MPEG-DASH andan event described with regard to the triggering application informationwill be described. The event of the MPEG-DASH may be additionalinformation related to media time for aperiodic transmission to a DASHclient and/or an application. The event described with regard to thetriggering application information may indicate a time for triggering bya trigger. In detail, the event triggered by the trigger may indicatethat an application performs a specific operation. In addition, theevent triggered by the trigger may indicate a state change of anapplication. For distinguishing between the event of the MPEG-DASH andthe event triggered by the trigger, the event triggered by the triggerwill be referred to as a triggering event. In detail, the triggeringevent may indicate an event that is generated by the trigger.

FIG. 134 illustrating a matching relationship of trigger attribute, theMPD element, and the event message box, for signaling trigger typeinformation, according to an embodiment of the present invention.

The trigger type information may indicate a type of a trigger fortriggering an application. For example, the trigger type information mayinclude at least one of a trigger for signaling a position of triggeringapplication information (i.e. TPT), a trigger for signaling a state ofan application, a trigger for signaling an action of an application,and/or a trigger for signaling media time.

The broadcast server 10 may transmit the trigger type information as theevent of the MPEG-DASH. In this case, the scheme identifier elementincluded in the event stream element of the MPD may include informationfor identifying a scheme of a message included in the event. Forexample, the scheme identifier element may include information usingsyntax of uniform resource name (URN) or uniform resource locator (URL).The value element included in the event stream element of the MPD mayinclude a value for the event stream. For example, the value element mayinclude trigger type information indicating a type of a trigger fortriggering an application. The broadcast receiving apparatus 100 mayreceive the trigger type information based on the event stream elementof the MPD. In detail, the broadcast receiving apparatus 100 may extracta scheme identifier element and/or a value element from the event streamelement of the MPD and receive the trigger type information.

In another detailed embodiment, a scheme identifier field included inthe event message box may include information for identifying a schemeof the event message box. for example, the scheme identifier field mayinclude information using syntax of uniform resource name (URN) oruniform resource locator (URL). The value field including the eventmessage box may include a value of an event. For example, the valuefield may include trigger type information indicating a type of atrigger for triggering an application. The broadcast receiving apparatus100 may receive the trigger type information based on the event messagebox. In detail, the broadcast receiving apparatus 100 may extract ascheme identifier field and/or value field of the event message box andreceive trigger type information.

FIG. 135 illustrates trigger type information according to an embodimentof the present invention.

The trigger type information may indicate a type of a trigger fortriggering an application. For example, the trigger type information mayinclude at least one of a trigger for signaling a location of triggeringapplication information (i.e. TPT), a trigger for signaling a state ofan application, a trigger for signaling an action of an application,and/or a trigger for signaling media time.

According to an embodiment of the present invention, the broadcastserver 10 may identify the trigger type information based on a valuefield of the value element and/or the event message box of the eventstream element of the MPD and transmit the trigger type information tothe broadcast receiving apparatus 100. Hereinafter, the value elementand/or the value field value will be referred to as value information. Avalue corresponding to the value information may be changed and/oradded.

For example, when the value information indicates “tpt”, the triggertype information may indicate a trigger for triggering a location of thetriggering application information (i.e. TPT). The location of thetriggering application information may be represented in the form of auniform resource identifier (URI). The URI may include uniform resourcelocator (URL) and/or uniform resource name (URN). The URL may beinformation indicating a location of a network of web resource. The URNmay be information for identifying resource according to a name of aspecific namespace. When the URN indicates a location in On-line, alocation of the triggering application information may be represented as“http://[domain]/[directory]”. When the URN indicates a location on asession (e.g. FLUTE session, ROUTE session, and ALC/LCT session), thelocation of the triggering application information may be represented as“file://[ip_address]/[path]”. That is, the scheme identifier elementand/or the scheme identifier field may be represented ashttp://[domain]/[directory] and/or “file://[ip_address]/[path]”.

When the value information indicates “status”, the trigger typeinformation may indicate a trigger for signaling a status (or lifecycle)of an application. The status of the application may include at leastone of preparing, execution, termination, and/or suspending.

When the value information indicates “action”, the trigger typeinformation may indicate a trigger for signaling an action of anapplication.

When the value information indicates “mediatime”, the trigger typeinformation may indicate a trigger for signaling media time.

FIG. 136 illustrates the syntax of triggering application informationaccording to an embodiment of the present invention.

According to an embodiment of the present invention, in anext-generation hybrid broadcast system, when the broadcast server 10transmits trigger type information using a trigger, action informationmay be omitted from the aforementioned triggering applicationinformation.

FIG. 137 illustrates a matching relationship of trigger attribute, theMPD element, and the event message box, for signaling a position ofinformation on a triggered application, according to an embodiment ofthe present invention.

The broadcast server 10 may transmit a position of the triggeringapplication information as an event of MPEG-DASH. In this case, theidentifier attribute included in the event element of the MPD mayindicate an identifier for identifying the triggering applicationinformation. In addition, the position of the event may indicate aposition of the triggering application information. The broadcastreceiving apparatus 100 may receive triggering application informationbased on the event element. In detail, the broadcast receiving apparatus100 may extract a position of the triggering application informationfrom a message of the event and receive triggering applicationinformation.

In another detailed embodiment, an identifier field included in theevent message box may indicate an identifier for identifying triggeringapplication information. The message data field included in the eventmessage box may indicate a position of the triggering applicationinformation. The broadcast receiving apparatus 100 may receivetriggering application information based on the event message box. Indetail, the broadcast receiving apparatus 100 may extract a position ofthe triggering application information from the message data field ofthe event message box and receive the triggering applicationinformation.

As described above, the triggering application information may be TPT.

FIG. 138 illustrates a matching relationship of trigger attribute, theMPD element, and the event message box, for signaling a status of anapplication, according to an embodiment of the present invention.

The broadcast server 10 may transmit the status of the application as anevent of MPEG-DASH. In this case, the presentation start time elementincluded in the event element of MPD may indicate start time of thetriggering event. The identifier attribute included in the event elementof the MPD may indicate an identifier for identifying the triggeringapplication information. A message included in the event element mayindicate a status of an application. The broadcast receiving apparatus100 may change the application status based on the event element. Indetail, the broadcast receiving apparatus 100 may extract theapplication status from the message included in the event element andchange the application status. In detail, the broadcast receivingapparatus 100 may extract a state of an application from a messageincluded in an event element, extract event start time from thepresentation start time element, and change the state of the applicationat start time of the triggering event.

In another detailed embodiment, a presentation start delay time fieldincluding the event message box may indicate start tie of the triggeringevent. An identifier field including the event message box may indicatean identifier for identifying the triggering application information. Amessage data field included in the event message box may indicate astate of an application. The broadcast receiving apparatus 100 maychange a state of the application based on the event message box. Indetail, the broadcast receiving apparatus 100 may extract the state ofthe application from the message data field of the event message box andchange the state of the application. In a detailed embodiment, thebroadcast receiving apparatus 100 may extract the state of theapplication from the message data field of the event message box,extract start time of the triggering event from the presentation starttime delay field, and change the state of the application at start timeof the triggering event.

The state of the application may indicate at least one of preparing,execution, termination, and suspending.

As described above, the triggering application information may be TPT.

FIG. 139 is a matching relationship of trigger attribute, an MPDelement, and an event message box, for signaling an action of anapplication, according to an embodiment of the present invention.

The broadcast server 10 may transmit an action of an application as anevent of MPEG-DASH. In this case, a presentation start time elementincluded in an event element of MPD may indicate start time of thetriggering event. The presentation duration element included in theevent element of MPD may indicate a difference between start time of thetriggering event and termination time of the triggering event. Inanother detailed embodiment, the presentation duration element includedin the event element of MPD may indicate termination time of thetriggering event. The identifier attribute included in the event elementof MPD may indicate an identifier for identifying the triggeringapplication information. A message included in the event element mayindicate a carried-out action of an application. In detail, the messageincluded in the event element may include at least one of an applicationidentifier for identifying a triggered application, an identifier of anevent for identifying a triggering event, and a data identifier foridentifying data. In detail, the message included in the event elementmay have the aforementioned trigger format. In this case, the messageincluded in the event element may not include start time of thetriggering event included in the aforementioned attribute, terminationtime of the triggering event, and an identifier for identifying theprogram segment. For example, the message included in the event elementmay be xbc.tv/e12?e=7.5. The broadcast receiving apparatus 100 mayperform the action of the application based on the event element. Indetail, the broadcast receiving apparatus 100 may extract the action ofthe application from the message included in the event element andperform the action of the application. In detail, the broadcastreceiving apparatus 100 may extract the action of the application fromthe message included in the event element, extract start time of thetriggering event from the presentation start time element, and performthe action of the application at start time of the triggering event. Ina detailed embodiment, the broadcast receiving apparatus 100 may extractthe action of the application from the message included in the eventelement, extract start time of the triggering event from thepresentation start time element, and perform the action of theapplication prior to termination time of the triggering event afterstart time of the triggering event. The broadcast receiving apparatus100 may disregard the event message of MPEG-DASH upon receiving theMPEG-DASH event message after the termination time of the triggeringevent.

In another detailed embodiment, a presentation start delay time fieldincluding the event message box may indicate start time of thetriggering event. The presentation duration field included in the eventmessage box of the MPD may indicate a difference between start time ofthe triggering event and termination time of the triggering event. Inanother detailed embodiment, a presentation duration field including theevent message box of the MPD may indicate termination time of thetriggering event. The identifier field included in the event message boxmay indicate an identifier for identifying the triggering applicationinformation. The message data field included in the event message boxmay indicate the action of the application. In detail, the message datafield included in the event message box may include at least one of anapplication identifier for identifying a triggered application, anidentifier of an event for identifying a triggering event, and a dataidentifier for identifying data. In detail, the message data fieldincluded in the event message box may have the aforementioned triggerformat. In this case, the message data field included in the eventmessage box may not include start time of a triggering event included inthe aforementioned attribute, termination time of the triggering event,and an identifier for identifying the program segment. For example, themessage data field included in the event message box may bexbc.tv/e12?e=7.5. The broadcast receiving apparatus 100 may perform theaction of the application based on the event message box. In detail, thebroadcast receiving apparatus 100 may extract the action of theapplication from the message data field of the event message box andperform the action of the application. In a detailed embodiment, thebroadcast receiving apparatus 100 may extract the action of theapplication from the message data field of the event message box,extract start time of the triggering event from the presentation starttime delay field, and perform the action of the application at starttime of the triggering event. In a detailed embodiment, the broadcastreceiving apparatus 100 may extract the action of the application fromthe message data field of the event message box, extract start time ofthe triggering event from the presentation start time delay field, andperform the action of the application prior to termination time of thetriggering event after start time of the triggering event. The broadcastreceiving apparatus 100 may disregard the event message box uponreceiving the event message box after termination time of the triggeringevent.

FIG. 140 is a matching relationship of trigger attribute, an MPDelement, and an event message box, for signaling media time, accordingto an embodiment of the present invention.

The broadcast server 10 may transmit media time of content as an eventof MPEG-DASH. In this case, the presentation start time element includedin the event element of MPD may indicate media time of the content. Inthis case, the content may be content presented by the broadcastreceiving apparatus 100. The identifier attribute included in the eventelement of the MPD may indicate an identifier for identifying thetriggering application information. The broadcast receiving apparatus100 may extract media time of content based on the event element. Thebroadcast receiving apparatus 100 may generate a time line as areference of synchronization between a triggering event and contentbased on the media content of the content. In detail, the broadcastreceiving apparatus 100 may extract the media time of the content fromthe presentation start time element included in the event element andgenerate a time line as a reference of synchronization between thetriggering event and the content.

The presentation start time delay field included in the event messagebox of MPD may indicate media time of the content. In this case, thecontent may be content presented by the broadcast receiving apparatus100. The identifier attribute included in the event element of MPD mayindicate an identifier for identifying the triggering applicationinformation.

The broadcast receiving apparatus 100 may extract media time of thecontent based on the event message box. The broadcast receivingapparatus 100 may generate a time line as a reference of synchronizationbetween the triggering event and the content based on the media time ofthe content. In this case, the content may be content presented by thebroadcast receiving apparatus 100. In detail, the broadcast receivingapparatus 100 may extract media time of content from the presentationstart time delay field included in the event message box and generate atime line as a reference of synchronization between the triggering eventand the content.

Thereby, the broadcast receiving apparatus 100 may synchronize contentand triggering event even if the media time information included in thecontent is not extracted.

FIG. 141 illustrates definition of value attribute for signaling alltrigger attributes as one event according to an embodiment of thepresent invention.

In order to transmit a trigger as an event of MPEG-DASH, an eventelement may indicate a type of information signaled by a trigger. Indetail, value attribute included in the event stream element mayindicate that a trigger included in the message of an event signals aposition of the triggering application information. In this case, avalue of the value attribute may be tpt. The value attribute included inthe event stream element may indicate that a trigger included in themessage of the event signals a state of the application. In this case,the value of the value attribute may be status. The value attributeincluded in the event stream element may indicate that a triggerincluded in the message of the event signals the action of theapplication. In this case, the value of the value attribute may be anaction. The value attribute included in the event stream element mayindicate that a trigger included in the message of the event signalsmedia time of the content. In this case, the value of the valueattribute may be mediatime. The value attribute included in the eventstream element may indicate that all information items included in thetrigger included in the message of the event are included. In this case,the value of the value attribute may be a trigger.

In another detailed embodiment, the value field included in the eventmessage box may indicate that a trigger included in the data messagefield of the event message box signals a position of the triggeringapplication information. In this case, the value of the value field maybe tpt. The value field included in the event message box may indicatethat a trigger included in the data message field of the event messagebox signals a state of the application. In this case, the value of thevalue field may be status. The value field included in the event messagebox may indicate that a trigger included in the data message field ofthe event message box signals the action of the application. In thiscase, the value of the value field may be action. The value fieldincluded in the event message box may indicate that a trigger includedin the data message field of the event message box signals media time ofcontent. In this case, the value of the value field may be mediatime.The value field included in the event message box may indicate that alltrigger attributes included in a trigger of the data message field ofthe event message box are included. In this case, the value of the valuefield may be trigger, which will be described below in detail.

FIG. 142 illustrates a matching relationship of identifier attribute andmessage attribute of an event element, an identifier field of an eventmessage box, and a message data field, for signaling all triggerattributes as one event, according to an embodiment of the presentinvention.

As described above, all attributes to be included in a trigger may besignal as one event of MPEG-DASH.

When value information indicates “trigger”, the trigger type informationmay indicate a trigger for signaling all trigger attributes as oneevent.

In detail, the message of the event of the MPEG-DASH may include atleast one of an identifier for identifying a triggered application, anidentifier for identifying a triggering event, an identifier foridentifying data, start time of a triggering event, and termination timeof the triggering event.

In this case, the identifier attribute of the event element may indicatean identifier for identifying triggering application information. Themessage included in the event element may include a trigger itself. Indetail, the message of the event element may have the aforementionedtrigger format. The message included in the event element may be timedtext format of trigger.

The identifier field of the event message box may indicate an identifierfor identifying the triggering application information. The message datafield included in the event message box may include a trigger itself. Indetail, the message data field included in the event message box mayinclude the aforementioned format of trigger. The message data fieldincluded in the event message box may include the timed text format oftrigger.

Thereby, the broadcast server 10 may transmit a plurality of triggerattributes through one MPEG-DASH event message. The broadcast receivingapparatus 100 may acquire a plurality of trigger attributes through oneMPEG-DASH event message.

Furthermore, a trigger may be signaled through the MMT protocol. Thiswill be described below with reference to the attached drawings.

FIG. 143 shows a structure of a package of the MMT protocol according toan embodiment of the present invention.

As described above, the MMT protocol can be used as a protocol fortransmitting media content in hybrid broadcast. Transmission of mediacontent through the MMT protocol will be described through a package, anasset, a media processing unit (MPU) and presentation information (PI).

The package is a logical transmission unit of content transmittedthrough the MMT protocol. Specifically, the package can include the PIand the asset.

The asset is an encoded media data unit included in the package. In aspecific embodiment, the asset may indicate an audio track included incontent. Further, the asset may represent a video track included incontent. The asset may indicate a captioning track included in content.The asset may include one or more MPUs.

The MPU is a media processing unit of content transmitted through theMMT protocol. Specifically, the MPU may include a plurality of accessunits. Further, the MPU may include data in a different format such asMPEG-4 AVC or MPEG-TS.

The PI is media content presentation information described above.Specifically, the PI may include at least one of spatial information andtemporal information necessary to consume the asset. In a specificembodiment, the PI may be composition information defined in ISO-IEC23008-1.

The broadcast transmission device 10 may transmit the package in an MMTPpacket corresponding to a transmission unit of the MMT protocol. Datatypes included in a payload of the MMTP packet will be described withreference to the following figure.

FIG. 144 shows a structure of an MMTP packet and data types included inthe MMTP packet according to an embodiment of the present invention.

The MMTP packet according to an embodiment of the present invention mayhave the structure shown in FIG. 92(a). Particularly, the MMTP packetcan represent the type of data included therein through a type field.

The MMTP packet may include a fragment of the MPU in the payload.Further, the MMTP packet may include a generic object indicating generaldata in the payload. Specifically, the generic object may be onecomplete MPU. Further, the generic object may be an object of adifferent type. The MMTP packet may include a signaling message in thepayload. Specifically, the MMTP packet may include one or more signalingmessages. Further, the MMTP packet may include a fragment of a signalingmessage. The signaling message may be a unit of signaling informationthat signals media content transmitted through the MMT protocol. TheMMTP packet may include one repair symbol. In a specific embodiment, thebroadcast transmission device 10 can transmit application signalinginformation through the MMTP packet including a fragment of the MPU.Specifically, the broadcast transmission device 10 can transmit atrigger through the MMTP packet including a fragment of the MPU.

FIG. 145 shows a syntax of an MMTP payload header when the MMTP packetincludes a fragment of the MPU according to an embodiment of the presentinvention.

When the MMTP packet includes a fragment of the MPU, the payload headerof the MMTP packet may include a length field indicating lengthinformation of the payload of the MMTP packet. In a specific embodiment,the length field may be referred to as “length”. In a specificembodiment, the length field is a 16-bit field.

When the MMTP packet includes a fragment of the MPU, the payload headerof the MMTP packet may include a type field indicating the type of theMPU included in the payload of the MMTP packet. Specifically, when theMMTP packet includes a fragment of the MPU, the payload of the MMTPpacket may include at least one of a media fragment unit, MPU metadataand movie fragment metadata. The MPU metadata may include ftyp, mmpu andmoov of ISO BMFF and other boxes included among ftyp, mmpu and moov. Themovie fragment metadata includes a moof box and a media data excludedmdat box. The media fragment unit may include at least one of a sampleof media data and a sub-sample. Here, the media data may be one of timedmedia data and non-timed media data. In a specific embodiment, the typefield may be referred to as FT. In a specific embodiment, the lengthfield may be a 4-bit field.

When the MMTP packet includes a fragment of the MPU, the payload headerof the MMTP packet may include a timed flag indicating whether thefragment of the MPU includes timed media. Specifically, when the valueof the timed flag is 1, the timed flag can indicate that the MPUfragment included in the MMTP packet includes timed media. In a specificembodiment, the timed flag may be referred to as T. In a specificembodiment, the timed flag may be 1-bit flag.

When the MMTP packet includes a fragment of the MPU, the payload headerof the MMTP packet may include a fragment indicator indicating fragmentinformation of a data unit included in the payload. The data unit mayrepresent the unit of data included in the payload of the MMTP packet.The payload of the MMTP packet may include one or more data units. In aspecific embodiment, the fragment indicator may be referred to as f_i.In a specific embodiment, the fragment indicator may be a 2-bit field.

When the MMTP packet includes a fragment of the MPU, the payload headerof the MMTP packet may include an aggregation flag indicating that thepayload includes one or more data units. In a specific embodiment, theaggregation flag may be referred to as A. In a specific embodiment, theaggregation flag may be a 1-bit flag.

When the MMTP packet includes a fragment of the MPU, the payload headerof the MMTP packet may include a fragment counter field indicating thenumber of fragments included in the same data unit included in thepayload. When the aggregation flag indicates that one or more data unitsare included in the payload, the value of the fragment counter field maybe 0. In a specific embodiment, the fragment counter field may bereferred to as frqg_counter. In a specific embodiment, the fragmentcounter field may be an 8-bit field.

When the MMTP packet includes a fragment of the MPU, the payload headerof the MMTP packet may include an MPU sequence field indicating a numberof a sequence including the MPU fragment. In a specific embodiment, theMPU sequence field may be referred to as MPU_sequence number.

When the MMTP packet includes a fragment of the MPU, the payload headerof the MMTP packet may include a data unit length field indicating thelength of a data unit. Specifically, when the payload of the MMTP packetincludes one or more data units, the payload header of the MMTP packetmay include the data unit length field indicating a data unit length. Ina specific embodiment, the data unit length field may be referred to asDU length. In a specific embodiment, the data unit length field may be a16-bit field.

When the MMTP packet includes a fragment of the MPU, the payload headerof the MMTP packet may include a data unit header field indicating aheader of a data unit. The data unit header field has a format dependingon the type of data included in the data unit. Specifically, the dataunit header field may have a format depending on the value of theaforementioned type field. Transmission of application signalinginformation using this payload header syntax will be described withreference to the following figure.

FIG. 146 shows synchronization of content with a trigger transmittedthrough an MPU according to an embodiment of the present invention.

The broadcast transmission device 10 may transmit application signalinginformation through a track of ISO BMFF by transmitting the same throughan MPU. Accordingly, the broadcast transmission device 10 can transmitthe application signaling information such that the applicationsignaling information is synchronized with content on a frame-by-framebasis. Specifically, the broadcast transmission device 10 can transmitthe application signaling information through the aforementioned payloadheader syntax of the MMTP packet such that the application signalinginformation can be synchronized with content on a frame-by-frame basis.In a specific embodiment, the broadcast transmission device 10 can setthe fragment type of the MPU to the media fragment unit, insert theapplication signaling information into the data unit payload andtransmit the application signaling information. Further, the broadcasttransmission device 10 may set the timed flag such that the timed flagindicates transmission of timed media. Specifically, the broadcasttransmission device 10 can set the timed flag such that the timed flagindicates transmission of timed media when the application signalinginformation needs to be transmitted at a specific time like a trigger.When application signaling information included in a data unit is atrigger, the trigger may have the aforementioned form. In anotherspecific embodiment, the trigger may have a timed text form. Further,the trigger may be XML. In addition, the trigger may include anapplication ID that identifies a triggered application. Further, thetrigger may include a triggering event ID that identifies a triggeringevent. The trigger may include an action indicating an action of atriggered application. Further, the trigger may include a data ID thatidentifies data necessary for a triggering event. In addition, thetrigger may include a triggering event start time. The trigger mayinclude a triggering event end time. As described above, the broadcastreception device 10 can perform an action after the triggering eventstart time and before the triggering event end time. Specifically, theapplication signaling information can be synchronized with a moviefragment presented in a decided sequence at a decided time through thetrigger. In a specific embodiment, the broadcast transmission device 10may set the triggering event start time and triggering event end time onthe basis of a media time in the movie fragment. Further, the broadcasttransmission device 10 may set the triggering event start time andtriggering event end time to relative time in the trigger. Otherwise,the broadcast transmission device 10 may set the triggering event starttime and triggering event end time to time based on wall-clock providedthrough out-of-band. For example, the broadcast transmission device 10can set the triggering event start time and triggering event end time totime based on wall-clock provided by CI. Further, the broadcasttransmission device 10 may set the triggering event start time andtriggering event end time to time based on wall-clock provided bytimestamp descriptor( ).

In the embodiment of FIG. 146, a first trigger (Trigger 1) issynchronized with a first movie fragment (Movie Fragment 1) and a secondtrigger (Trigger 2) is synchronized with a second movie fragment (MovieFragment 2). Specifically, the first trigger signals the position oftriggering application information according to the above-describedtrigger format and triggers a triggering event having a triggering eventID of 5 to be immediately executed for an application having anapplication ID of 7. The second trigger signals the position oftriggering application information according to the above-describedtrigger format and triggers a triggering event having a triggering eventID of 3 to be executed between 77 ee to 80 ee for an application havingan application ID of 8.

The broadcast transmission device 10 may transmit an applicationsignaling message as a signaling message of the MMT protocol. This willbe described with reference to the following figure.

FIG. 147 shows a syntax of an MMT signaling message according to anotherembodiment of the present invention.

The MMT signaling message according to an embodiment of the presentinvention may include a message ID identifying the signaling message. Ina specific embodiment, the message ID may be referred to as message id.In a specific embodiment, the message ID may be a 16-bit field.

In addition, the MMT signaling message may include version informationindicating update history of the signaling message. In a specificembodiment, the version information may be referred to as “version”. Ina specific embodiment, the version information may be an 8-bit field.

The signaling message may include length information indicating thelength of data included therein. The length information may be referredto as “length”. In a specific embodiment, the length information may bea 16-bit or 32-bit field.

The signaling message may include extension information indicating laterextension of the signaling message. The signaling message may includevarious types of information. This will be described with reference tothe following figure.

FIG. 148 shows a relationship between a value of an ID identifying anMMT signaling message and data signaled by the MMT signaling messageaccording to another embodiment of the present invention.

Specifically, the signaling message may be a PA message indicatinginformation of all signaling tables. Here, the message ID may be 0x0000.The signaling message may be an MPI message including media contentpresentation information. Here, the message ID may be 0x0001 to 0x000F.The signaling message may be an MPT message including an MP tableindicating information of an asset included in a package. Here, themessage ID may be 0x0011 to 0x001F. Further, the signaling message maybe a CRI message including a CRI table indicating synchronizationinformation. Here, the message ID may be 0x0200. The signaling messagemay be a DCI message including a DCI table indicating device performancenecessary to consume a package. Here, message ID may be 0x0201. Further,the signaling message may be an AL_FEC message indicating FECinformation necessary to receive an asset. Here, the message ID may be0x0202. The signaling message may be an HRBM message indicating a memoryand end-to-end transmission delay necessary for the broadcast receptiondevice 100. Here, the message ID may be 0x0203. To transmit applicationsignaling information, the signaling message may be an applicationsignaling message including application signaling information other thanthe aforementioned messages. The broadcast reception device 100 canidentify the type of a message included in the signaling message throughthe above-described message ID. Here, the message ID may be 0x8000. Theform of the application signaling message will be described withreference to the following figure.

FIG. 149 shows a syntax of a signaling message including applicationsignaling information according to another embodiment of the presentinvention.

The application signaling message according to another embodiment of thepresent invention may include an application signaling table includingapplication signaling information in the signaling message. In aspecific embodiment, the signaling message may include a plurality ofapplication signaling tables.

The application signaling message may include table number informationindicating the number of application tables included in the applicationsignaling message. In a specific embodiment, the table numberinformation may be referred to as number of tables. The table numberinformation may be an 8-bit field.

The application signaling message may include table ID information thatidentifies an application table included therein. In a specificembodiment, the table ID information may be referred to as table_id. Thetable ID information may be an 8-bit field.

The application signaling message may include table version informationindicating signaling table update history. In a specific embodiment, thetable version information may be referred to as table_version. In aspecific embodiment, the table version information may be an 8-bitfield.

The application signaling message may include table length informationindicating the length of a signaling table. In a specific embodiment,the table length information may be referred to as table_length. In aspecific embodiment, the table length information may be an 8-bit field.A detailed syntax of the application signaling table will be describedwith reference to the following figure.

FIG. 98 shows a syntax of an application signaling table includingapplication signaling information according to another embodiment of thepresent invention.

The application signaling table according to another embodiment of thepresent invention may include an ID that identifies the applicationsignaling table. In a specific embodiment, the ID may be calledtable_id. The ID may be an 8-bit field.

The application signaling table may include version informationindicating application signaling table update history. In a specificembodiment, the version information may be called “version”. In aspecific embodiment, the version information may be an 8-bit field.

The application signaling table may include length informationindicating the length thereof. In a specific embodiment, the lengthinformation may be called “length”. In a specific embodiment, the lengthinformation may be a 16-bit field.

The application signaling table may include trigger type informationindicating the type of a trigger included therein. The signaling tablemay include various types of triggers. This will be described withreference to the following figure.

FIG. 151 shows a relationship between trigger type information includedin the application signaling table and trigger properties included intriggers according to another embodiment of the present invention.

A trigger included in the signaling table can signal the position oftriggering application information. Here, the trigger type informationmay be 1. Further, the trigger included in the signaling table cansignal the lifecycle of an application. Specifically, the triggerincluded in the signaling table can signal an application status. Here,the trigger type information may be 2. The trigger included in thesignaling table can signal an application action. Here, the trigger typeinformation may be 3. In addition, the trigger included in the signalingtable can signal a media time of content. Here, the trigger typeinformation may be 4. Further, the trigger included in the signalingtable can include all types of information that can be included in thetrigger. Here, the trigger type information may be 5. Description willbe given with reference to FIG. 150.

In a specific embodiment, the trigger type information may be calledtrigger_type. In a specific embodiment, the trigger type information maybe an 8-bit field.

Signaling information table may include text indicating a trigger.Specifically, the signaling information table may include characterinformation indicating characters included in the trigger. In a specificembodiment, the signaling information table may include multiple piecesof character information. In a specific embodiment, the characterinformation may be called URI_character. Further, the trigger may havethe aforementioned form. In a specific embodiment, the characterinformation may be an 8-bit field.

In the embodiment described with reference to FIGS. 150 and 151, triggertypes are represented through the trigger type information in theapplication signaling message table. In this case, the broadcastreception device 100 needs to parse the application signaling table torecognize a trigger type. Accordingly, the broadcast reception device100 cannot selectively receive only a necessary trigger. A method forsolving this problem will be described with reference to the followingfigure.

FIG. 152 shows a relationship between a value of an ID identifying anMMT signaling message and data signaled by the MMT signaling messageaccording to another embodiment of the present invention.

The broadcast transmission device 10 can set the message ID foridentifying an application signaling message depending on the type of atrigger included in the application signaling message. Specifically, thebroadcast transmission device 10 can set the message ID depending onwhether the trigger is a trigger signaling the position of triggeringapplication information, a trigger signaling an application lifecycle, atrigger signaling an application action, a trigger signaling a contentmedia time or a trigger including all trigger information. Specifically,when the message ID is 0x8000 to 0x8004, the message ID can indicatethat the signaling message is an application signaling message. In aspecific embodiment, when a trigger included in the applicationsignaling message signals the position of triggering applicationinformation, the message ID may be 0x8000. When the trigger included inthe application signaling message signals an application lifecycle, themessage ID may be 0x8001. When the trigger included in the applicationsignaling message signals an application action, the message ID may be0x8002. When the trigger included in the application signaling messagesignals a content media time, the message ID may be 0x8003. When thetrigger included in the application signaling message includes alltrigger information, the message ID may be 0x8004. Since the message IDof the signaling message indicates the type of a trigger included in theapplication signaling message, the application signaling table may notinclude the trigger type information. In the embodiment of FIG. 153, theapplication signaling table does not include the trigger typeinformation differently from the aforementioned application signalingtable.

When the message ID identifying the application signaling message is setdepending on the type of a trigger included in the signaling message, asdescribed above, the broadcast reception device 100 can recognize atrigger type without parsing the application signaling table included inthe application signaling message. Accordingly, the broadcast receptiondevice 100 can selectively receive a specific type of triggerefficiently.

The broadcast transmission device 10 can transmit the applicationsignaling information through a generic packet. This will be describedwith reference to the following figure.

FIG. 154 shows a structure of an MMTP packet according to anotherembodiment of the present invention.

First of all, the syntax of the MMTP packet will be described.

The MMTP packet may include version information indicating the versionof the MMTP protocol. In a specific embodiment, the version informationmay be referred to as V. In a specific embodiment, the versioninformation may be a 2-bit field.

The MMTP packet may include packet counter flag information indicatingpresence of packet counting information. In a specific embodiment, thepacket counter flag information may be referred to as C. In a specificembodiment, the packet counter flag information may be a 1-bit field.

The MMTP packet may include FEC type information indicating a scheme ofan FEC algorithm for preventing errors in the MMTP packet. In a specificembodiment, the FEC type information may be referred to as FEC. In aspecific embodiment, the FEC type information may be a 2-bit field.

The MMTP packet may include extension flag information indicatingpresence of header extension information. In a specific embodiment, theextension flag information may be referred to as X. In a specificembodiment, the extension flag information may be a 1-bit field.

The MMTP packet may include RAP (Random Access Point) flag informationindicating whether an RAP for data random access of a payload isincluded. In a specific embodiment, the RAP flag information may bereferred to as R. In a specific embodiment, the RAP flag information maybe a 1-bit field.

The MMTP packet may include type information indicating a data type ofthe payload. In a specific embodiment, the type information may bereferred to as type. In a specific embodiment, the type information maybe a 6-bit field.

The MMTP packet may include packet ID information indicating an IDidentifying the packet. The broadcast reception device 100 can determinean asset including the corresponding packet on the basis of the packetID information. Further, the broadcast reception device 100 can acquirea relationship between the asset and the packet ID from the signalingmessage. The packet Id information may have a unique value for thelifetime of the corresponding transport session. In a specificembodiment, the packet ID information may be referred to as packet_id.In a specific embodiment, the packet ID information may be a 16-bitfield.

The MMTP packet may include packet sequence number informationindicating a packet sequence number. In a specific embodiment, thepacket sequence number information may be referred to aspacket_sequence_number. In a specific embodiment, the packet sequencenumber information may be a 32-bit field.

The MMTP packet may include timestamp information that specifies a timeinstance value of MMTP packet transmission. The timestamp informationmay be based on a UTC value. Further, the timestamp information mayrepresent a time when the first byte of the MMTP packet is transmitted.In a specific embodiment, the timestamp information may be referred toas timestamp. In a specific embodiment, the timestamp information may bea 32-bit field.

The MMTP packet may include packet counting information indicating acount of transmitted packets. In a specific embodiment, the packetcounting information may be referred to as packet counter. In a specificembodiment, the packet counting information may be a 32-bit field.

The MMTP packet may include FEC information which is necessary accordingto an FEC protection algorithm. In a specific embodiment, the FECinformation may be referred to as Source_FEC_payload_ID. In a specificembodiment, the packet counting information may be a 32-bit field.

The MMTP packet may include reserved header extension information forlater header extension. In a specific embodiment, the header extensioninformation may be referred to as header_extension.

The broadcast transmission device 10 can insert application signalinginformation into a generic type packet. Specifically, the broadcasttransmission device 10 can insert the application signaling informationinto a payload of the generic type packet in the form of a file andtransmit the application signaling information. Here, the broadcasttransmission device 10 can allocate different packet IDs to files. Thebroadcast reception device 100 can extract the application signalinginformation from the generic packet. Specifically, the broadcastreception device 100 can extract a file including the applicationsignaling information from the generic packet. Specifically, thebroadcast reception device 100 can extract the file including theapplication signaling information on the basis of the packet ID of thegeneric packet. For example, the broadcast reception device 100 candetermine whether the packet includes necessary application signalinginformation on the basis of the packet ID of the generic packet.

The broadcast transmission device 10 may transmit the applicationsignaling information using the header extension information of the MMTPpacket. This will be described with reference to the following figure.

FIG. 155 shows a structure of an MMTP packet and a syntax of a headerextension field for application signaling information transmissionaccording to another embodiment of the present invention.

The broadcast transmission device 10 may insert the applicationsignaling information into the header of the MMTP packet and transmitthe same. Specifically, the broadcast transmission device 10 may insertthe application signaling information into the header extensioninformation and transmit the same.

In a specific embodiment, the header extension information may includeheader extension type information indicating the type of headerextension information included therein. Here, the header extension typemay indicate that the header extension information includes anapplication signaling message. In another specific embodiment, theheader extension type information may indicate the type of applicationsignaling information included in the header extension information.Here, the type of application signaling information may include atrigger type depending on the aforementioned trigger property. In aspecific embodiment, the header extension type information may bereferred to as type.

In a specific embodiment, the header extension information may be a16-bit field. In a specific embodiment, the header extension informationmay include header extension length information indicating the length ofthe header extension information. Here, the header extension lengthinformation may indicate the length of the application signalinginformation included in the header extension information. In a specificembodiment, the header extension length information may be referred toas length. In a specific embodiment, the header extension informationmay be a 16-bit field.

In a specific embodiment, the header extension information may include aheader extension value indicating extension information includedtherein. Here, the header extension value may represent applicationsignaling information included in the header extension information.Here, the application signaling information may be a trigger. Further,the type of the application signaling information may be a URI in astring form. The URI in a string form may be the aforementioned stringtype trigger. In a specific embodiment, the header extension value maybe referred to as header_extension_value.

Accordingly, the broadcast reception device 100 can extract theapplication signaling information from the header extension information.Specifically, the broadcast reception device 100 can extract theapplication signaling information on the basis of the header extensiontype information included in the header extension information.Specifically, the broadcast reception device 100 can determine whetherthe header extension information includes the application signalinginformation on the basis of the header extension type information. Thebroadcast reception device 100 can extract the application signalinginformation when the header extension information includes theapplication signaling information. Further, the broadcast receptiondevice 100 can determine the type of the application signalinginformation included in the header extension information on the basis ofthe header extension type information. Accordingly, the broadcastreception device 10 can selectively acquire the application signalinginformation.

Description will be given of operations of the broadcast transmissiondevice 10 and the broadcast reception device 100 according totransmission and reception of application signaling information inaccordance with the above-described embodiments of the present inventionwith reference to the following figures.

FIG. 156 shows part of a broadcast system according to an embodiment ofthe present invention.

In a future hybrid broadcast system, an interactive application relatedto broadcast programs may be delivered through a broadcast network orthe Internet and provided to users. To deliver the interactiveapplication to a receiver, a service worker, one type of web workers ofHTMLS which can be generally used in a browser environment, may be used.

The service worker may automatically store content items related to theinteractive application in a storage of the receiver depending oncharacteristics of type of the interactive application. Otherwise, thecontent items related to the application may be stored in the receiverby a user.

The receiver can provide a mechanism that can operate similarly to apackage application or a widget through the service worker and can driveapplications even in an offline state such as an Internet-disconnectedstate.

An embodiment of the present invention relates to a method of installingthe interactive application in the receiver through the service workerand/or interworking with addLink( ) API to provide applicationmanagement functions such as execution, termination, update and/ordeletion of the interactive application when a user wants.

The broadcast system according to an embodiment of the present inventionincludes a receiver J104100, a content provider/broadcaster J104200and/or an application service server J104300.

The receiver J104100 may include a signaling parser J104110, anapplication manager J104120, an application browser (or an applicationprocessor) J104130, a service worker J104132, a (non-real-time) NRTcontent manager J104140 and/or a storage J104150.

The signaling parser J104110 is a device or a module for parsing asignal sent from the content provider/broadcaster. The signal mayinclude signaling information (or signaling data) and/or content. Thesignaling information including application related information isacquired. The signaling information may include command information foridentifying a command related to application execution.

The application manager J104120 is a device or a module for managing anapplication when the application is present after the signal is parsed.The application manager J104120 generates a control signal with respectto an application action using information included in the signalinginformation.

The application browser (or application processor) J104130 is a deviceor a module for performing a process for executing an application. Theapplication browser J104130 processes the application according to acontrol signal. The application browser J104130 can perform interactivecommunication between the receiver and a server (or broadcaster), whichis necessary for a procedure through which the application is providedto a user.

The service worker J104132 may be included in the application browser orincluded as a separate device in the receiver. The service workerJ104132 is a module or a device for managing downloading of NRT contentor application related information from a server provided by the contentprovider/broadcaster.

The NRT content manager J104140 is a module or a device for managingnon-real-time (NRT) content. The NRT content manger J104140 processesNRT content transmitted in non real time.

The storage J104150 is a device storing data. The storage used in thepresent invention may include an internal storage of the receiver, acache in a browser for driving the interactive application and/or anexternal storage (e.g., external USB storage) connected to the receiver.The storage J104150 provides applications and/or signaling informationstored therein to the service worker J104132 or the application browserJ104130. The storage J104150 can receive and store an applicationthrough interactive communication with the application service server.

The application used in the present invention may correspond to anapplication provided by the content provider/broadcaster. Theapplication may provide an independent service or may be combined withbroadcast content to provide a service with higher quality to users. Theapplication can operate by activating (or launching), suspending,resuming or terminating (or exiting) actions.

The content provider/broadcaster J104200 provides content in thebroadcast system. The content provider/broadcaster J104200 can deliversignaling information related to the application to the receiver. Thecontent provider/broadcaster J104200 can transmit signaling informationand/or NRT content to the receiver through an NRT transmission network.The NRT content may include broadcast content and/or the application.

The application service server J104300 is a server providing datarelated to the application.

FIG. 157 shows an example in which a storage is included in thebroadcast system according to an embodiment of the present invention.

The storage may be included in the broadcast system as an internalstorage J105100, a cache memory J105200 and/or an external storageJ105300.

The internal storage J105100 may correspond to a storage device includedin the receiver.

The cache memory J105200 may correspond to a storage device included inthe application browser.

The external storage J105300 may be a storage device outside thereceiver and may correspond to a general external storage device, aserver or a cloud storage. When the external storage J105300 correspondsto the server or cloud storage, the receiver and the external storageare connected through networking and the receiver can rapidly receivedata about an application at the request of a receiver user.

FIG. 158 shows operation of the service worker according to anembodiment of the present invention.

The service worker, a web worker of HTML5, can be driven by theapplication browser that can execute an application in the receiver. Theservice worker may be created to be activated when an initialapplication is executed or when a user wants. The service worker may bepositioned between the application server and a web application executedin the receiver to serve as a proxy for a network request transmitted tothe application server. When the service worker is activated, theservice worker processes a request for application content items whenthe application executed in the receiver sends the request to theapplication server. The service worker can receive and/or process aresponse from the application server.

The application content items may refer to the application or subsidiarycontent necessary to present the application.

FIG. 159 shows operation of the service worker in an offline stateaccording to an embodiment of the present invention.

The advantage of the service worker as a proxy role is that the serviceworker can store all or some application content items on theapplication server in a cache.

The cache can be used differently from a cache generally used in abrowser, and the cache defined in the service worker can be completelymanually controlled.

As shown, the receiver can execute an application even when the receiveris not connected to the Internet using application content itemsdownloaded from the application server and stored in the cache by theservice worker. In this case, the application browser can deliver arequest for the application content items to the service worker and theservice worker can check whether application content items suitable forthe request are present in the cache and deliver corresponding data tothe application browser.

FIG. 160 shows an application program interface (API) and metadata usedfor a receiver to execute an application according to an embodiment ofthe present invention.

As described above, the interactive application can be installed in thereceiver and provided to a user. When application content items for theinteractive application in a web application form are stored in adatabase (DB) (or a storage) or a cache by the service worker, thereceiver can execute the interactive application like a widget even inan offline state (i.e., the Internet is not connected). The interactiveapplication can call addLink( ) API of the application manager of thereceiver. Here, the application manger provides metadata related to theapplication to the application browser or the service worker such thatthe receiver can configure a page or a menu for a link.

When the user is viewing a program through the receiver, applicationnotification indicating presence of the interactive application relatedto the program may be displayed on the screen. The user inputs a commandfor executing the application to the receiver. The service worker in thereceiver may be registered or may register the application or the usercommand. An install button may be displayed during execution of theapplication and the user may install the application by selecting theinstall button. The service worker may control application content itemsto be downloaded and stored in a storage (an internal storage, anexternal storage or a cache). An application registration procedure ofthe service worker may include application installation and/orapplication activation. The application may call addLink( ) API of theapplication manager of the receiver. When the addLink( ) API is called,related metadata may be delivered to the application manager of thereceiver such that the application manager can configure an applicationwidget page. The application manager of the receiver may configure anapplication collection page and/or menu using the delivered metadata.Users may order operations of executing, terminating, updating and/ordeleting installed applications using the application collection page ormenu. When a user executes an installed application, the user may callthe URL of the application. When application content items correspondingto the URL are stored in the storage, the service worker may load theapplication content items from the storage.

The URL of the interactive application in a web application form may bestored in the receiver. The interactive application calls the addLink( )API of the application manage of the receiver, and metadata related tothe application may be delivered to the application manger such that thereceiver can configure a page or a menu for a link.

When a user is viewing a program through the receiver, applicationnotification indicating presence of the interactive application relatedto the program may be displayed on the screen. The user inputs a commandfor executing the application to the receiver. The service worker maynot be registered. In this case, the service worker may not downloadapplication content items which will be used in an offline state. Theinstall button may be displayed during execution of the application andthe user may input a command for selecting the install button to thereceiver. The application may call the addLink( ) API of the applicationmanager. When the addLink( ) API is called, related metadata may bedelivered from the application such that the application manager of thereceiver can configure an application link page. The application managerof the receiver may configure an application collection page or menuusing the delivered metadata. Users may input a command for executing,terminating, updating and/or deleting installed applications to thereceiver. A user may control link to the URL of an installed applicationto be executed to load application content items.

Table (a) of the figure shows an embodiment of addLink( ) API of theapplication manager. When the addLink( ) API is successfully called, thereceiver adds a link to a list of links. The integer returns a valueindicating whether the API has been successfully called and, whencalling fails, returns a value indicating the reason of failure. TheaddLink( ) may be called application link information. The applicationlink information includes a link and/or application property informationnecessary to execute an application.

The addLink( ) may include URI information and/or linkmetadatainformation.

The URI information indicates a URI value of a URL stored as a link. TheURI information may indicate a URL stored as a link for an application.

The linkmetadata information includes metadata related to a link. Thelinkmetadata information will be described in detail below.

Table (b) of the figure shows values returned by the addLink( ) APO anddefinition thereof. When “0” is returned, this value indicatessuccessful calling and addition of a link. When “1” is returned, thisvalue indicates that calling fails because the syntax of URI informationis not valid. When “2” is returned, this value indicates that callingfails because the linkmetadata information is not valid. When “3” isreturned, this value indicates that calling fails because the number ofstored links exceeds a permitted limit.

Table (c) of the figure shows a schema table of the linkmetadatainformation. The linkmetadata information may include @url information,@title information, @majChanNum information, @minChanNum information,@channelName information, @programName information, @expirationinformation, @packagedApp information, @description information, a Paramelement, @title information, @description information, an Icon element,@source information, @width information and/or @height information.

The @url information indicates a URL related to a link. The @urlinformation may represent the URL of an object indicated by a link.

The @title information indicates a link title displayed to a user.

The @majChanNum information indicates a major channel number of avirtual channel for which a link is provided. When the link is providedthrough an NRT service, this information can indicate some values (e.g.,upper 8 bits) of service_id information of the NRT service included in aservice map table (SMT).

The @minChanNum information indicates a minor channel number of avirtual channel for which a link is provided. When the link is providedthrough an NRT service, this information can indicate some values (e.g.,lower 8 bits) of service_id information of the NRT service included inthe service map table (SMT).

The @channelName information indicates a short name of a virtual channelfor which a link is provided. When the link is provided through an NRTservice, this information can indicate the same information asshort_service_name information of the NRT service included in theservice map table (SMT).

The @programName information indicates title_text (a title representedby characters) of a program (e.g., a PSIP event, a broadcast program, abroadcast event or an event in an application) for which a link isprovided.

The @expiration information indicates an expiration date at which a linkbecome invalid.

The @packagedApp information indicates whether a linked URL correspondsto a widget or a packaged application. The receiver can recognizewhether the linked URL is a link for acquiring an application or awidget using this information. When the receiver is not connected to theInternet and the linked URL corresponds to the link for acquiring anapplication, application management such that shading may be performedsuch that the application cannot be executed.

The @description information indicates description about an application.

The Param element may be used to indicate a query string following a URLfor a link to an application. For example, in a URL ofhttp(s)://app.example.com/index.html?type=value, “type=value” maycorrespond to the Param element. For example, applications may bediscriminated by Param element values although they use the same URL.The application manager of the receiver may use the Param element togroup or search for applications associated with the same broadcaster orthe same program. A broadcaster or a content provider can efficientlymanage applications by discriminating the applications using Paramelement values without assigning different URLs to the applications.

The @title information indicates a title for the Param element.

The @description information indicates description about the Paramelement.

The Icon element identifies an icon file used to indicate a link in adisplay of links to a user. A plurality of icon files may be present.For example, icon files having different sizes or indicating the samelink may be present. One of such icon files may be displayed accordingto situation.

The @source information indicates a URL of an image file for an iconindicated by the Icon element.

The @width information indicates the width of an icon image in pixelunits.

The @height information indicates the height of an icon image in pixelunits.

FIG. 161 shows a user interface (UI) with respect to an application or alink for an application according to an embodiment of the presentinvention.

The receiver may provide a UI through which a user can select a desiredapplication or a link providing the application.

The aforementioned information included in the addLink( ) may be usedwhen the receiver provides the UI. For example, the receiver can displayan icon for an application or a link for the application using the Iconelement, @source information, @width information and/or @heightinformation. The receiver can display a title of an application or alink for the application using the @title information. The receiver candisplay information describing an application or a link in the UI usingthe @description information.

FIG. 162 shows a process through which a receiver installs and executesan application in the form of a widget according to an embodiment of thepresent invention.

An application in the form of a widget may be installed and executedusing the service worker and the addLink( ) API.

When the URL of an interactive application ishttp(s)://app.example.com/index.html, there may be multiple links (orURLs) for application content items included in the application, asshown.

The receiver may receive signaling information related to theapplication. The receiver may deliver the signaling information relatedto the application to the application manager (step 1).

The application manger may acquire the URL of the application includedin the signaling information and execute the application (step 2).

After execution of the application URL, application content items may bedownloaded through a broadcast network and/or the Internet when theservice worker is registered automatically or by a user (step 3).

The service worker may store the application content items in a storage(internal storage/browser cache/external storage) after downloading theapplication content items (step 4).

The application (or application browser) may call addLink( ) and delivermetadata related to the link of the application to the applicationmanger (step 5).

The application manager may store the delivered metadata in the storage(internal storage/browser cache/external storage) (step 6).

FIG. 163 shows a process through which a user executes an applicationupon installation of the application according to an embodiment of thepresent invention.

The URL of the application may be http(s)://app.example.com/index.htmland URLs or links of application content items may be as shown in thefigure.

A user may input a command for executing the application to the receiverthrough an installed app menu in the receiver. The installed app menumay be implemented in the form of a UI using metadata included inaddLink( ) as described above (step 1).

The application manger may execute the application URL. The applicationmanager may execute the application indicated by the URL. When the userselect a specific application, the application manger may be configuredto acquire the URL corresponding to the selected application and toexecute the application corresponding to the URL (step 2).

In a process through which the application or browser loads theapplication URL, the service worker is driven to load applicationcontent items stored in the storage. Since all application content itemsfor application execution are stored in the storage, the receiver cannormally operate the application even when the receiver is not connectedto the Internet.

As described above, according to the embodiments of the presentinvention, the broadcast receiver can correctly execute a desiredapplication of a viewer at an appropriate time even when the broadcastreceiver is not connected to the Internet or does not receive datarelated to the application through the current broadcast network, inapplication execution in the broadcast receiver.

FIG. 164 is a flowchart illustrating a method of executing anapplication by a broadcast receiver according to an embodiment of thepresent invention.

The broadcast receiver receives application signaling informationincluding information about an application (JS112010). The applicationsignaling information may be included in a broadcast signal andtransmitted, and the broadcast receiver may parse the applicationsignaling information from the broadcast signal.

The broadcast receiver parses application URL information including aURL at which a specific application can be acquired from the applicationsignaling information (HS112020).

The broadcast receiver receives one or more application content itemsrelated to the application identified by the application URL (JS112030).

The broadcast receiver stores the received application content items(JS112040).

All or some technical features described above may be added to each stepof the method of executing an application by the broadcast receiveraccording to an embodiment of the present invention.

FIG. 165 is a diagram showing an API according to an embodiment of thepresent invention.

The Widget API according to the embodiment of the present invention mayinclude at least one of an install Widget( ) API, anonWidgetInstallation( ) API, a startWidget( ) API and/or a widgets( )API.

The installWidget( ) API (or ApplicationMana,ger,installWidget) is anAPI used to install an application. An application browser mayasynchronously call an installWidget( ) API of an application manager.The application browser (or a receiver) may install and/or add a widgetin and/or to a list of widgets (e.g., applications) based on theinstallWidget( ) API. The application (or the widget) installed in thereceiver may be referred to as a packaged App.

The onWidgetinstallation( ) API (orApplicationManager.onWidgetInstallation) is an API used for a callbackroutine (or a callback function) to report on installation progress of awidget (e.g., an application)

The startWidget( ) API (or ApplicationManager.startWidget) is an APIused to launch an installed widget (e.g., a packaged application).

The widgets( ) API (or ApplicationManager.widgets) is an API used toreturn a list of installed widgets (e.g., a packaged application).

The application browser (or the receiver) may call at least one of theabove-described widget APIs.

FIG. 166 is a diagram showing an installWidget( ) API according to anembodiment of the present invention.

A side for providing an application (or a widget) cannot add anapplication to a list of applications (or a list of widgets) of a TVusing only an installation function of the application.

Accordingly, the installWidget( ) API according to the embodiment of thepresent invention may further include widgetMetadata as an argument toprovide a function for installing an application and a function foradding an application to the list of applications.

The integer return value of the installWidget( ) API shall indicatewhether or not the call of the install Widget( ) API was successful. Ifthe call of the install Widget( ) API failed, the integer return valueof the installWidget( ) API shall provide the reason for failure.

The application browser (or the receiver) according to the embodiment ofthe present invention may call the installWidget( ) API of theapplication manager, The installWidget( ) API may include a uri argumentand/or a widgetMetadata argument as arguments. That is, the applicationbrowser (or the receiver) may deliver the uri argument and/or thewidgetMetadata argument to the application manager, upon calling theinstallWidget( ) API of the application manager.

The uri argument may be a resource locator in the form of a URI, whichpoints to an application (or a widget package) to be installed.

The widgetMetadata argument shall represent metadata to be associatedwith the application. The widgetMetadata argument takes the form of aUTF-8 representation of an XML document. The widgetMetadata argument maybe the same as the above-described linkMetadata argument except the rootelement. That is, the root element of the widgetMetadata argument may bea widgetMetadata element.

For example, the widgetMetadata argument (or the widgetMetadata element)may include a url attribute, a title attribute, a majChanNum attribute,a minChanNum attribute, a channelName attribute, a prograniNameattribute, an expiration attribute, a packagedApp attribute, adescription attribute, a Param element, and an Icon element. Details ofthe attributes and/or elements included in the widgetMetadata argumentmay include all details of the above-described information havingsimilar names.

FIG. 167 is a diagram showing an addWidget( ) API according to anembodiment of the present invention.

The Widget API according to the embodiment of the present invention mayfurther include an addWidget( ) API. In this case, the above-describedinstallWidget( ) API may include only a uri argument as an argument,

The install Widget( ) API according to an embodiment of the presentinvention may provide a function for installing an application. TheaddWidget( ) API according to an embodiment of the present invention maybe separated from the above-described installWidget( ) API to provide afunction for adding an application to a list of applications.

The integer return value of the addWidget( ) API shall indicate whetheror not the call of the addWidget( ) API was successful. If the call ofthe addWidget( ) API failed, the integer return value of the addWidget() API shall provide the reason for failure.

The application browser (or the receiver) according to the embodiment ofthe present invention may call the addWidget( ) API of the applicationmanager. The addWidget( ) API may include a uri argument and awidgetMetadata argument as arguments. That is, the application browser(or the receiver) may deliver the uri argument and/or the widgetMetadataargument to the application manager, upon the addWidget( ) API of theapplication manager.

Details of the uri argument and/or widgetMetadata argument included inthe addWidget( ) API may include all details of the an argument and/orthe widgetMetadata argument included in the above-describedinstallWidget( ) API.

FIG. 168 is a diagram showing a getLinks( ) API according to anembodiment of the present invention.

When the receiver is not connected to the Internet (or in the case of apackaged application), the receiver (or the application browser) mayacquire a list of applications (that is, the packaged application)installed in the receiver based on the widgets( ) API.

When the receiver is connected to the Internet (or in the case of alink), the Widget API according to the embodiment of the presentinvention may further include a getLinks( ) API.

The getLinks( ) API according to the embodiment of the present inventionshall provide information on a list of links capable of being connectedto an application in a server. The getLinks( ) API according to theembodiment of the present invention shall provide information on thelist of inkMetadata of links in the receiver.

The list of links returned in the getLinks( ) API may be a string in theform of a list composed of linkMetadata.

The receiver according to the embodiment of the present invention mayacquire the list of applications (that is, the packaged application)installed in the receiver based on the widgets( ) API.

In addition, the receiver according to an embodiment of the presentinvention may acquire the list of links based on the getLinks( ) API.

FIG. 169 is a diagram showing a checkApplication(API according to anembodiment of the present invention.

Referring to FIG. 169(a), the Widget API according to an embodiment ofthe present invention may further include a checkApplication( ) API.

The checkApplication( ) API may provide information on whether the sameapplication (e.g., packaged application or link) exists in the receiver.The integer return value of the checkApplication( ) API shall representwhether the same application (e.g., packaged application or link) existsin the receiver.

The application browser (or the receiver) may call the checkApplication() API of the application manager. The checkApplication( ) API mayinclude a metadata argument as an argument. That is, the applicationbrowser (or the receiver) may deliver the metadata argument to theapplication manager, upon calling the checkApplication( ) API of theapplication manager.

The metadata argument shall represent the metadata to be associated witheither the packaged application or the link. The metadata argument takesthe form of a UTF-8 representation of an XML document. The metadataargument may be the same as the above-described linkMetadata argumentexcept the root element. That is, the root element of the metadataargument may be a metadata element.

For example, the metadata argument (or the metadata element) may includea url attribute, a title attribute, a majChanNum attribute, a minChanNumattribute, a channelName attribute, a programName attribute, anexpiration attribute, a packagedApp attribute, a description attribute,a Param element, and/or an Icon element. Details of the attributesand/or elements included in the metadata argument may include alldetails of the above-described information having similar names.

The receiver (or the application browser) may call the checkApplication( ) API before calling the installWidget( ) API and/or the addLink( )API. The receiver may check whether the same application as anapplication to be installed exists at an application level based on thecheckApplication( ) API. That is, the checkApplication( ) API may checkwhether the same application is installed in the receiver and/or whetherthe same link is added and return an integer return value.

Referring to FIG. 169(b), the integer return value of thecheckApplication( ) API according to the embodiment of the presentinvention is shown. The integer return value of the checkApplication( )API according to the embodiment of the present invention may be referredto as a code value.

For example, if the code value is ‘0’. this shall indicate that the sameapplication (or widget) is not installed in the receiver or the samelink does not exist, Accordingly, the application can be installed inand/or added to the receiver.

For example, if the code value is ‘1’, this shall indicate that the sameapplication (or widget) is installed in the receiver or the same linkexists. Accordingly, the application cannot be installed in and/or addedto the receiver.

FIG. 170 is a diagram showing an installWidget( ) API according to anembodiment of the present invention.

In the case of a packaged application, the install Widget( ) APIaccording to the embodiment of the present invention may change anexisting return type to return error codes. For example, one of errorcodes may indicate that the same application (or widget) is installed inthe receiver.

Referring to FIG. 170(a), the install Widget( ) API according to theembodiment of the present invention may provide a function forinstalling an application and a function for adding an application to alist of applications. Details of the installWidget( ) API may includeall details of the above-described installWidget( ) API.

Referring to FIG. 170(b), an integer return value may be referred to asa code value.

If the code value is ‘0’, this indicates that the call succeeded and awidget (or an application) was added.

If the code value is ‘1’, this indicates that the call failed and thereason for failure is that the syntax of the URI argument was invalid.

If the code value is ‘2’, this indicates that the call failed and thereason for failure is that the format of the widgetMetadata argument wasinvalid.

If the code value is ‘3’, this indicates that the call failed and thereason for failure is that the number of stored widgets (orapplications) exceeded an upper limit.

If the code value is ‘4’, this indicates that the call failed and thereason for failure is that the same application (or widget) was alreadyinstalled in the receiver.

FIG. 171 is a diagram showing an addLink( ) API according to anembodiment of the present invention.

In the case of a link, the addLink( ) API according to the embodiment ofthe present invention may change an existing return type to return errorcodes. For example, one of the error codes may indicate that the samelink exists in the receiver.

Referring to FIG. 171(a), the addLink( ) API according to the embodimentof the present invention may include a function for adding a link to alist of links. Details of the addLink( ) API may include all details ofthe above-described addLink( ) API.

Referring to FIG. 171(b), an integer return value may be referred to asa code value.

If the code value is ‘0’, this indicates that the call succeeded and alink was added.

If the code value is ‘1’, this indicates that the call failed and thereason for failure is that the syntax of the URI argument was invalid.

If the code value is ‘2’, this indicates that the call failed and thereason for failure is that the format of the linkMetadata. argument wasinvalid.

If the code value is ‘3’, this indicates that the call failed and thereason for failure is that the number of stored links exceeded an upperlimit.

If the code value is ‘4’, this indicates that the call failed and thereason for failure is that the same link already exists in the receiver.

FIG. 172 is a diagram showing a broadcast transmission method accordingto an embodiment of the present invention.

A broadcast transmission apparatus may generate service data (orsignaling information for a service using a controller (not shown)(CS1720100).

Here, the service data may include app-based enhancement components.Here, the signaling data. may include application signaling informationassociated with transmission of the app-based enhancement components.Here, the app-based enhancement components may include a primary device(PD) application. Here, the application signaling information mayinclude application information indicating a uniform resource locator(URL) for providing the location of the PD application.

In addition, the broadcast transmission apparatus may generate low-levelsignaling data and/or service layer signaling data using the controller(CS1720200).

In addition, the broadcast transmission apparatus may transmit abroadcast signal including the service data, the low-level signalingdata and the service layer signaling data through a transmission unit(CS1720300).

The low-level signaling data may support bootstrapping of serviceacquisition. For example, the low-level signaling data may include theabove-described FTC.

The service layer signaling data may include first signaling data,second signaling data and third signaling data.

The first signaling data may include reference signal referring to thesecond signaling data and the third signaling data. For example, thefirst signaling data may include the above-described USD and/or SMT.

The second signaling data may include a description for the component ofthe service. For example, the second signaling data may include theabove-described MPD.

The third signaling data may include acquisition information of thecomponent related to the service. For example, the third signaling datamay include at least one of an SDP, an SMT. a CMT, a ROUTE sessionelement, an LCT session element, and/or an LSID.

FIG. 173 is a diagram showing a broadcast reception method according toan embodiment of the present invention.

The receiver according to the embodiment of the present invention mayinclude a reception module and/or a controller. The controller mayinclude an application processor, a companion module and/or a web socketserver.

The receiver according to the embodiment of the present invention mayreceive a broadcast signal including signaling data for a service andservice data (CS1730100),

Here, the service data may include app-based enhancement components,Here, the signaling data may include application signaling informationassociated with transmission of the app-based enhancement components.Here, the app-based enhancement components may include a primary-device(PD) application.

The receiver may install the PD application using an applicationprocessor (or an application browser) (CS1730200).

The receiver may perform a discovery process with a CD applicationexecuted in a companion device (CD) using the companion module(CSI730300).

The receiver may establish a web socket connection among the web socketserver of the PD, the PD application and the CD application using thecompanion module (CS1730400).

The receiver may receive an emergency alert (EA) message includingemergency alert information through a broadcast network or broadbandusing the reception module (CS1730500).

The receiver may deliver the EA message to the CD through the web socketconnection using the web socket server (CS1730600)

In addition, the receiver may receive a request for a device descriptionfrom the CD application and transmit a first response message, using thecompanion module. Here, the header of the first response message mayinclude a first URI, used as a web server end point of the PD.

In addition, the receiver may receive, from the CD application, arequest for application information made from the first URL and transmita second response message, using the companion module, Here, the secondresponse message may include a second URL used as a web socket end pointof the PD.

Here, the application signaling information may include applicationinformation indicating a uniform resource locator (URL) for providingthe location of the PD application,

The receiver may call an install widget application programminginterface (API) for installing the PD application in the PD using anapplication processor. Here, the install widget API may include at leastone argument. Here, the at least one argument may include URIinformation indicating the PD application and metadata informationindicating metadata associated with the PD application. Here, theinstall widget API may provide a response message. Here, the responsemessage may indicate that the same PD application was already installedin the PD.

The above-described steps may be omitted or replaced with other steps ofperforming the same or similar operations.

Modules or units may be processors executing consecutive processesstored in a memory (or a storage unit). The steps described in theaforementioned embodiments can be performed by hardware/processors.Modules/blocks/units described in the above embodiments can operate ashardware/processors. The methods proposed by the present invention canbe executed as code. Such code can be written on a processor-readablestorage medium and thus can be read by a processor provided by anapparatus.

While the embodiments have been described with reference to respectivedrawings for convenience, embodiments may be combined to implement a newembodiment. In addition, designing computer-readable recording mediastoring programs for implementing the aforementioned embodiments iswithin the scope of the present invention.

The apparatus and method according to the present invention are notlimited to the configurations and methods of the above-describedembodiments and all or some of the embodiments may be selectivelycombined to obtain various modifications.

The methods proposed by the present invention may be implemented asprocessor-readable code stored in a processor-readable recording mediumincluded in a network device. The processor-readable recording mediumincludes all kinds of recording media storing data readable by aprocessor. Examples of the processor-readable recording medium include aROM, a RAM, a CD-ROM, a magnetic tape, a floppy disk, an optical datastorage device and the like, and implementation as carrier waves such astransmission over the Internet. In addition, the processor-readablerecording medium may be distributed to computer systems connectedthrough a network, stored and executed as code readable in a distributedmanner.

Although the preferred embodiments of the present invention have beendisclosed for illustrative purposes, those skilled in the art willappreciate that various modifications, additions and substitutions arepossible, without departing from the scope and spirit of the inventionas disclosed in the accompanying claims. Such modifications should notbe individually understood from the technical spirit or prospect of thepresent invention.

Both apparatus and method inventions are mentioned in this specificationand descriptions of both the apparatus and method inventions may becomplementarily applied to each other.

Those skilled in the art will appreciate that the present invention maybe carried out in other specific ways than those set forth hereinwithout departing from the spirit and essential characteristics of thepresent invention. Therefore, the scope of the invention should bedetermined by the appended claims and their legal equivalents, not bythe above description, and all changes coming within the meaning andequivalency range of the appended claims are intended to be embracedtherein.

In the specification, both the apparatus invention and the methodinvention are mentioned and description of both the apparatus inventionand the method invention can be applied complementarily.

[Mode for Invention]

Various embodiments have been described in the best mode for carryingout the invention.

INDUSTRIAL APPLICABILITY

The present invention is applied to broadcast signal providing fields.

Various equivalent modifications are possible within the spirit andscope of the present invention, as those skilled in the relevant artwill recognize and appreciate. Accordingly, it is intended that thepresent invention cover the modifications and variations of thisinvention provided they come within the scope of the appended claims andtheir equivalents.

1-14. (canceled)
 15. A device for processing a broadcast signal, thedevice comprising: a tuner configured to receive the broadcast signalincluding a signal frame including content for a service, applicationsignaling information for one or more applications that are related tothe service and signaling information for discovering the applicationsignaling information for the service, wherein: the signalinginformation including service category information representing acategory of the service, the application signaling information includingURL information of HTML (Hypertext Markup Language) files associatedwith the one or more applications; a frame parser configured to parsethe signal frame; a time de-interleaver configured to time de-interleavedata in the signal frame based on a TI (Time Interleaving) block; adecoder configured to decode the time de-interleaved data; a displayscreen configured to display application information about the one ormore applications, the application information including at least one ofdescriptions of the one or more applications, icons representing the oneor more applications, or titles of the one or more applications,wherein: in response to a selection signal of an application of the oneor more applications, a controller configured to execute the applicationbased on the application information, the display screen is furtherconfigured to display an installation button for installation of theexecuted application, and in response to an installation signal of theexecuted application, the controller is further configured to installthe executed application.
 16. The device of claim 15, wherein thecontent is delivered via one or more ROUTE sessions.
 17. The device ofclaim 15, wherein the installation button is displayed during executionof the application.
 18. The device of claim 15, wherein the displayscreen is further configured to display a menu for ending, updating anddeleting operation of the installed application.
 19. A method ofprocessing a broadcast signal, the method comprising: receiving thebroadcast signal including a signal frame including content for aservice, application signaling information for one or more applicationsthat are related to the service, and signaling information fordiscovering the application signaling information for the service,wherein: the signaling information including service categoryinformation representing a category of the service, the applicationsignaling information including URL information of HTML (HypertextMarkup Language) files associated with the one or more applications;parsing the signal frame; time de-interleaving data in the signal framebased on a TI (Time Interleaving) block; decoding the timede-interleaved data; displaying application information about one ormore applications, the application information including at least one ofdescriptions of the one or more applications, icons representing the oneor more applications, or titles of the one or more applications,wherein: in response to a selection signal of an application of the oneor more applications, a controller configured to execute the applicationbased on the application information, displaying an installation buttonfor installation of the executed application; and in response to aninstallation signal of the executed application, the controller isfurther configured to install the executed application.
 20. The methodof claim 19, wherein the content is delivered via one or more ROUTEsessions.
 21. The method of claim 19, wherein the installation button isdisplayed during execution of the application.
 22. The method of claim19, wherein the method includes: displaying a menu for ending, updatingand deleting operation of the installed application.
 23. A device forprocessing a broadcast signal, the device comprising: an encoderconfigured to encode data of the broadcast signal; a time interleaverconfigured to time interleave the encoded data based on a TI (TimeInterleaving) block; a frame builder configured to build a signal frameincluding the time interleaved data; and a transmitter configured totransmit the broadcast signal including the signal frame, the signalframe including content for a service, application signaling informationfor one or more applications that are related to the service andsignaling information for discovering the application signalinginformation for the service, the signaling information including servicecategory information representing a category of the service, theapplication signaling information including URL information of HTML(Hypertext Markup Language) files associated with the one or moreapplications.
 24. The device of claim 23, wherein the content isdelivered via one or more ROUTE sessions.
 25. The device of claim 23,wherein the signaling information further includes URL information toacquire the application information and an MPD (Media PresentationDescription).
 26. A method for processing a broadcast signal, the methodcomprising: encoding data of the broadcast signal; time interleaving theencoded data based on a TI (Time Interleaving) block; building a signalframe including the time interleaved data; and transmitting thebroadcast signal including the signal frame, the signal frame includingcontent for a service, application signaling information for one or moreapplications that are related to the service and signaling informationfor discovering the application signaling information for the service,the signaling information including service category informationrepresenting a category of the service, the application signalinginformation including URL information of HTML (Hypertext MarkupLanguage) files associated with the one or more applications.
 27. Themethod of claim 26, wherein the content is delivered via one or moreROUTE sessions.
 28. The method of claim 26, wherein the signalinginformation further includes URL information to acquire the applicationinformation and an MPD(Media Presentation Description).
 29. The deviceof claim 23, wherein the content is delivered via one or more ROUTEsessions.
 30. The device of claim 23, wherein the signaling informationfurther includes URL information to acquire the application informationand MPD(Media Presentation Description).